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FOREWORD 


Presented herein are the results of the A str ionics Laboratory in-house 
Phase B baseline design of the Spacelab Data Management System (DMS) . 
There were many contributors to this document but some of the major ones 
were the Instrumentation and Communication Division, the Systems/Projects 
Office, and the Computers Division, all of the Astrionics Laborator}^; Sperry 
Rand, direct support contractor for Astrionics Laboratory; and IBM’s Elec- 
tronics Systems Center, Huntsville, Alabama. 

The report is organized into two major parts; pages 1 through 63 
describe the rudiments of the DMS in-house baseline design, while the remain- 
der of the report consists of appendices of backup studies and investigations 
used to derive the baseline. The ideas and appi'oaches presented are those 
which evolved during the time frame April 1, 1973, to November 1, 1973. 
However, these basic concepts are presently being implemented in the Concept 
Verification Testing (CVT) program. 
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nondestructive readout 

OBC 

onboard checkout 

ows 

Orbital Workshop 

PACS 

pointing and attitude control subsystem 

RAM 

random access memory 

RDAU 

remote data acquisition unit 

RI/RO 

record in/record out 

ROM 

read-only memory 

SEPB 

standard experiment pointing base 

SOS 

s il i c on- on- s apphir e 

STDN 

Spaceflight Tracking and Data Network 

TBM 

(Ampex) Terabit Memory (System) 

TDM 

time division multiplex 

TDRS 

Tracking and Data Relay Satellite (system) 

TRIU 

tape recorder interface unit 

TSP 

twisted shielded pair 

TTL 

transistor-transistor logic 

UV 

ultraviolet 

WB 

wideband 

wc 

word count 
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Abbreviations 

Definiti 

A 

ampere 

av 

average 

BER 

bit error rate 

bps 

bit per second 

dB 

decibel 

dBm 

decibel above 1 milliwatt 

ft 

foot 

in. 

inch 

K 

thousand 

kbs 

kilobit per second 

kg 

kilogram 

kHz 

kilohertz 

lb 

pound 

M 

million 

Mbs 

megabit per second 

MHz 

megahertz 

MU 

megohm 

m 

meter 

mA 

milliampere 
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max 

maximum 

min 

minimum, minute 

msec 

millisecond 

jisec 

microsecond 

nsec 

nanosecond 

pF 

picofarad 

sec 

second 

Vac 

volt alternating current 

Vdc 

volt direct current 

VSWR 

voltage standing wave ratio 

W 

watt 
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1. 0 INTRODUCTION AND SCOPE 


The data management subsystem (DMS) integrates the avionics equipment 
into an operational system by providing the computations, logic, signal flow, and 
interfaces needed to effectively command, control, monitor and check out the 
experiment and subsystem hardware. Also, the DMS collects/retrieves experi- 
ment data and other information by recording and by command of the data relay 
link to ground. 

The major elements of the DMS are the computer subsystem, data acqui- 
sition and distribution subsystem, controls and display subsystem, onboard 
checkout subsystem, and software. 

This report documents the results of the DMS portion of the Spacelab 
Phase B Concept Definition Study and defines MSFC's DMS design reference 
model. The following sections provide a detailed description of the DMS and 
its major subsystems. Related studies and trade-offs are presented in the 
appendices. 


2.0 REQUIREMENTS 

2.1 GENERAL MISSION REQUIREMENTS 

Present NASA planning has identified approximately 40 Spacelab payloads 
to be flown over a 10 yr period. For the Spacelab to be able to accommodate 
the many different payloads, the DMS must be of a highly flexible design that 
permits rapid payload changeovers with a minimum of changes to Spacelab sub- 
system hardware. 


2.2 FUNCTIONAL REQUIREMENTS 

The following is a summary of the DMS functional requirements: 
1* Display data/information to operator/scientist, 

2. Respond to operator/scientist inputs and requests. 

3. Schedule, monitor, and control experiments. 

4. Monitor, sequence, and control subsystems. 
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5. Provide logic, processing, and computations, as required, for 
supporting subsystems operations. 

6. Provide for data acquisition, distribution, processing, and storage, 

7. Provide limited experiment data processing. 

8. Provide onboard checkout for subsystems and experiments, 

9. Provide the capability for inflight verification of the status of 
Space lab subsystems and experiments. 


2.3 DESIGN REQUIREMENTS 

The following is a listing of applicable Spacelab- level and DMS-level 
design requirements. 1 

1. The Spacelab will be designed for an operational life of at least 50 
seven- day missions with ground refurbishment. The design will also include 
provisions, if they are cost-effective, for growth in mission duration of up 
to 30 days. 


2. The Spacelab will be designed for a high probability (0. 95) of 
mission success. This will be measured by proper functioning of the module, 
its systems and subsystems, and experiment support equipment provided to 
the user; mission success does not require successful completion of all experi- 
ments. This level of mission success will be assured by component and sub- 
system reliability, redundancy, and onboard maintenance, as appropriate. 

3. In-flight maintenance of the Spacelab shall be limited to minor 
adjustments and replacements. No scheduled in-flight maintenance shall be 
performed during the 7-day mission. 

4. Standardized mechanical, electrical, data bus, and fluid interfaces 
between the Spacelab and the payload/experiment equipment shall be developed. 


1. The primary source for these requirements is the Sortie Lab Phase B Study, 
System Requirements; MSFC Sortie Lab Task 4.1.1, Oct. 6, 1972. 
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5. The Spacelab shall be equipped with a caution and warning (C&W) 
system to alert personnel in the Spacelab and Or biter of hazardous conditions in 
the Spacelab. The Spacelab shall contain C&W system monitor and display unit 
compatible with the C&W system of the interfacing Orbiter element. 

6. The controls and displays (C&D) shall make optimal use of multi- 
function displays and keyboards in conjunction with the DMS for control and 
monitoring of subsystems and experiments. The C&D subsystem shall provide 
the following functions: 

a. Payload crew station console (control and displays for payload 
and subsystems) . 

b. Caution and warning displays and alarms. 

c. Voice intercom. 

d. Closed circuit television. 

7. Onboard checkout shall be utilized to perform malfunction detection 
and to conduct subsystem and payload equipment checkout, monitoring, and 
fault isolation to a level optimized for cost, safety, maintenance, and repair 
requirements. The onboard checkout (OBC) subsystem shall be implemented 
in a manner which makes maximum use of data management, control and dis- 
play, and sensor hardware required for normal subsystems monitor and control 
functions. 


8. Natural environment data as specified in NASA T MX- 64 66 8 will be 
used for design and operational analyses. 


3.0 DMS DESIGN REFERENCE MODEL SUMMARY 

The following paragraphs provide a summary description of the DMS 
design reference model with its salient features and interfaces. Detailed 
descriptions are provided in Section 4. 


3.1 DMS DESCRIPTION SUMMARY 

The DMS design reference model is illustrated in Figure 1 and a sum- 
mary of the DMS characteristics are given in Table 1. The following paragraphs 
give a brief summary description of the DMS functional subsystems and software. 
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DIGITAL DATA 
TO/FROM ORBITER 



Figure 1. DMS design reference model. 


3.1.1 Computer 


The computer subsystem consists of a central processing unit (CPU) , 
main memory, input-output processor (IOP), and an auxiliary memory. The 
CPU is a 32-bit, floating point, mic reprogrammable, high speed (400 KADS) 2 
digital processor. The main memory provides 32K of 32-bit words of storage 
which is used for storing the basic flight program and data used frequently by 


2. KADS is the abbreviation for thousand equivalent adds per second. 


4 

















TABLE 1. DMS CHARACTERISTICS SUMMARY 


Central Processing Unit (CPU ) 

— 32-Bit Parallel Data Flow 

— 400 KADS 

— Fixed and Floating Point Arithmetic 

— Microprogrammed 

— 64K Words Directly Addressable 

Input-Output Processor (IOP ) 

— Performs All Input-Output (I/O) 

— Primary Control for Data Bus 

— Interfaces are Functionally Compatible With 
Widely Used Commercial Computer System 

Main Memory 

— 32 Bits + Parity 

— 2 jusec Cycle Time 

Computer Interface Unit (ClU'i 

— Formats Words for Data Bus 

— Generates Timing and Synchronization for Bus 

— Performs Serial-to-Parallel Conversion on Data to 
Computer and Parallel-to-Serial Conversion on Data 
from Computer 

— Distributes Timing 


Data Bus 

— 2 Mbs Bi-Phase 

— 20-Bit Word with 16-Bit Data 

— Twisted and Shielded Pairs 

Data Interface Unit (DlUi 

— Standard Interfaces 

— 128 Discrete Inputs 

— 128 Discrete Outputs 

— 128 Analog Inputs 

— 4 Analog Outputs 

— 8 Record In/Record Out 

— Performs 16 Instructions 

— Scans Discretes 

— Limit-Checks Analogs 

Data Exchange Control Unit (DECD) 

— Handles High Bit Rate Data 

— One of 20 Inputs Switched to any One of 20 Outputs 




the computer. The CPU has the capability of addressing up to 64K words of 
main memory. The IOP is a computer- type device that controls data flow 
within the DMS; it interfaces with the CPU, main and auxiliary memories, and 
the computer interface unit (CIU). The auxiliary memory provides storage 
for software programs and data that are to be used only periodically during 
flight* Final sizing and selection of the auxiliary memory is dependent on the 
final definition of the experiment support requirements. 


3*1*2 Software 


Software implementation for Spacelab features a modular concept which 
uses an operating system (executive) which controls subsystem and experiment 
application programs. The DMS software, or operating system, is a flexible, 
general purpose program which controls all software tasks and scheduling, 
performs nonchanging services for the application programs, and accommodates 
application program changes. The application programs software is that 
required for subsystems or experiment support and is, in general, mission 
dependent. 

A high-order language (HOL) selected from the languages under cur- 
rent development is proposed to reduce software development and verification 
time. For current planning, Houston aerospace language (HAL) is the HOL 
to be used for the onboard flight program, and the computer sizing estimates 
reflect this choice. 


3. 1 . 3 Data Acquisition and Distribution ( DA&D) 

The DA&D subsystem consists of a data bus subsystem, data exchange 
control unit (DECU) and recorders. The 2- Mbs (each way) data bus trans- 
fers data /commands between the DMS and the subsystems, experiments, and 
orbiter. The data bus is under control of the computer via the CIU. The 
DIUs interface the data bus to the experiments and subsystems to both receive 
and transmit data/commands. Both high (data bus rate) and low rate data/ 
commands can be transmitted and received. A DECU provides switching for 
routing scientific or housekeeping data to the onboard recorders and/or to the 
orbiter communications subsystems. 
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3.1.4 Controls and Displays 

The C&D subsystem provides the facilities for crew interface and inter- 
action with the Spacelab subsystems and experiments. This capability is located 
in the habitable area of the Spacelab. Some additional preentry C&D capability 
is located in the Orbiter for monitoring and operation of the Spacelab electrical 
power and environmental control subsystem prior to crew entry into the Space- 
lab habitable area. 

The Support Module C&D console provides the capability for independent 
operation by two Spacelab crewmen simultaneously. This console interfaces 
with the Spacelab computer, other subsystems, and experiments via the DMS 
data bus. Limited hardwire connections are provided. Two display systems 
are provided and each includes two CRT display units, one alphanumeric key- 
board, and one multifunction display symbol generator. Each multifunction 
display provides the capability for independent display of computer-generated 
alphanumeric and graphics data as well as video information. Two 3-axis hand 
controllers are provided for pointing TV cameras, telescopes, cameras, celes- 
tial sensors and trackers, standard experiment point base (SEPB) slew com- 
mands, and for vehicle attitude positioning by inputting rate commands to the 
control moment gyro (CMG) subsystem. Advisory display, C&W panels, time 
displays, intercom system, microfilm to video converters, and closed circuit 
TV are provided. Additional console space is provided for dedicated subsystem 
and experiment C&D. 

The pallet-only C&D provides the same type of capabilities as the Sup- 
port Module C&D except the console is configured for only one man. 


3. 1, 5 Onboard Checkout 


The OBC subsystem utilizes the data management subsystem plus a 
built-in testing capability in the subsystems and experiments to implement its 
functional requirements. The OBC is used both during prelaunch and flight. It 
provides stimuli to activate subsystem and then monitors, checks, and displays 
the test data and test results. 


3. 1, 6 Communications 


The present baseline approach is for the Spacelab to utilize the Orbiter 
communication system. Tracking and Data Relay Satellite (TDRS) system 
will permit near continuous real-time transmissions and greatly reduce the 
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requirement for onboard storage (magnetic tapes) of experimental data. The 
communication channels that are needed for Spacelab are listed in Table 2; 
these data are based on Orb iter interface with both the Spaceflight Tracking 
and Data Network (STDN) and TDRS, 


TABLE 2. COMMUNICATIONS CHANNELS 


Command 

Rate/Bandwidth 

Band 

Return Link (Orbiter to Earth) 



Digital 

50 Mbs 

Ku 

Analog/ Video 

5 MHz 

Ku 

Voice 

(TBD) 

Ku or S 

Telemetry 

25 kbs 

Ku or S 

Forward Link (Earth to Orbiter) 



Command 

8 kbs 

Ku or S 

Voice 

(TBD) 

Ku or S 

Video 

(TBD) 

Ku 


3. 2 DMS DESIGN CHARACTERISTICS 

The DMS concept was designed to provide a flexible capability to meet 
a variety of experiment and subsystem requirements. The primary consid- 
erations were provisions for a modular concept which could easily accommodate 
additional requirements, standardization of interfaces with subsystems and 
experiments, and components with flexibility for meeting a variety of opera- 
tions. 
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3.2.1 


DMS Modularity 


The DMS provides for modularity at both the subsystem and component 
level. The DMS design reference model, shown in Figure 1, shows the sim- 
plex DMS with a single data bus and using one channel of the IOP, The modular 
design for the DMS and IOP provides the capability for expansion. Since experi- 
ment requirements may be large or unique, a second data bus system could be 
added, allowing one data bus dedicated to subsystems and another data bus ded- 
icated to experiments. This is illustrated in Figure 2, Additional modular 
capability could be provided by dedicating a simplex DMS to subsystems and 
another to experiments, as shown in Figure 3. Connections between IOPs 
would allow communications between systems. If additional capability were 
required, two data buses could be provided for each IOP as shown in Figure 4, 

In addition to system modularity, subsystem components also offer mod- 
ularity features: Additional CPUs can be added to obtain multiprocessing 
capability, additional modules can be added to main storage (up to 64K) , and 
a varying number of DIUs (up to 32) can be provided on the data bus. The 
DIUs have the capability to add or delete analog, discrete, and digital I/O 
capability in modular quantities. The C& D panels also allocate space for 
addition of equipment. The number of components such as the C PU and the 
IOP can be varied to meet redundancy or support requirements. The software 
is modular in design to readily accommodate new or revised subsystem and 
experiment application software modules. 


AUX 

MEMORY 


OIU 


OIU 






CPU 





uP 


cm 


IOP 


Hj 


SUBSYSTEMS 


EXPERIMENTS 


CIU 


DIU 


OIU 

nut, tun 


EXP 


EXP 


ss 


mnr 


OIU 


tLXJ 




DIU 


EXP 


Figure 2. Single IOP with multiple data bus concept. 
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Figure 3. Dual IOP with single data bus concept. 



Figure 4. Dual IOP with dual data bus concept. 
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3. 2. 2 DMS Standardization 


The DMS concept provides for standardization of interfaces with external 
subsystems. The IOP provides standard interfaces with the CPU, the storage 
devices, peripheral equipment, and the CIUs. The data bus/DIU system pro- 
vides a standardized interface with external subsystems and experiments. It 
provides standardized discrete, analog, and serial and parallel digital inputs 
and outputs. 

The DMS uses standardized operating system software to interface with 
application software modules. The methods of addressing, data transfer, and 
software manipulation have been standardized for ease in programming and 
software integration. 


3. 2. 3 DMS Multiple Applications 

The DMS components were selected to provide a flexible subsystem 
which is not mission dependent and which may be used for varied applications. 
The computer is a general purpose, digital computer with microprogram capa- 
bility. The microprogram feature uses software changes to directly adapt the 
computer for a specific program, while new or revised flight programs permit 
multiple computer applications. This approach provides an extremely flexible 
onboard capability. The IOP uses the same processor as the CPU, giving it 
flexibility for varied I/O applications, while the standardized interfaces allow 
communications with a wide variety of peripherals. 

As discussed previously, the IOP design allows a varying number of 
data buses and DMS configurations to be used. The data bus can handle up to 32 
DIUs, providing the capability to add or delete DIUs as required. The DIU 
modularity allows varying of DIU interface capability. A variety of input and 
output paths can be configured using the DECU. Tape recorders can be added 
or deleted, as required. 

The C&D subsystem provides a multifunction display capability which 
can present video, alphanumeric, and graphic data. The alphanumeric key- 
board provides the flexibility for man/machine real-time interface with the 
computer and other onboard subsystems. Spare panel capability is provided 
for mis sion- dependent C&D. 

The DMS components, except the C&D panel and tape recorders, are 
designed for cold plate mounting. This permits installation and use of the DMS 
in the Support Module which provides a controlled environment or on the pallet 
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in an exposed space environment. (The C&D panel and tape recorders must 
be located in a controlled environment for crew access and convenience. ) 


3.3 DMS INTERFACES 

The interfaces between the Spacelab DMS and the Shuttle Orbiter sub- 
systems are shown in Figure 5. A two-way link is provided between the Space- 
lab data management subsystem and the shuttle computer subsystem for 
requesting and receiving navigational and timing data and for receiving com- 
mands/data from the ground. All data for transmission to ground stations are 
routed through the Spacelab data exchange control unit which interfaces with 
the Shuttle communications subsystem. If a pallet-only configuration were 
used, experiment data could be routed to the payload support station recorders 
located in the Orbiter. A C&W interface is provided to satisfy the Shuttle 
requirements for monitoring safety of the payload subsystems by the orbiter 
crew. An interface is provided between the Spacelab electrical power system 
(EPS) and the environmental control and life support subsystem (EC/LSS) 
and with the Orbiter C&D subsystem to provide the capability to power the 
Spacelab subsystems up-down from the Orbiter and to provide needed status 
data prior to the crew ! s entry into the Spacelab. Also, a two-way voice link 
is provided between the Orbiter and the Spacelab. 

The interfaces with other Spacelab subsystems and the experiments are 
through the data bus DIUs, with a few exceptions, such as hardware for the 
C&W subsystem. 

During ground checkout and prelaunch operations, the electrical support 
equipment ( ESE) will interface with the DMS and provide those command, 
control, data collection, and evaluation functions needed to assure flight read- 
iness. 


3.4 DMS PHYSICAL CHARACTERISTICS 


Table 3 is a listing of the DMS components and estimates of the space, 
weight, and electrical power requirements. For most missions the DMS com- 
ponents, except for part of the DIUs, are to be mounted in the Support Module. 
The DIUs are to be located where needed to minimize cabling. For a Spacelab 
pallet-only configuration, the DMS components, except C& D panel and tape 
recorders, are to be pallet- mo unted. 
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Figure 5. Spaeelab to Orbiter electrical interfaces. 


4.0 DMS DETAILED DESCRIPTION 

4. 1 COMPUTER SUBSYSTEM 

The computer subsystem consists of (l) a computer, which includes 
the CPU and the main memory (MM) ; (2) an auxiliary storage unit; and (3) 
an IOP. A block diagram of the computer subsystem is shown in Figure 6. 

The CPU provides the computational and processing capability for onboard 
processing and the main memory stores data and programs used frequently. 
The auxiliary storage device stores programs used infrequently. The IOP is 
an input/output processor which interfaces the CPU with the main and auxiliary 
memories, the data bus, and any peripherals used. 
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TABLE 3. DMS PHYSICAL CHARACTERISTICS 


Component 

No. Units 
Required 

Total 
Weight 
[kg (lb)] 

Total 

Power 

(W) 

Total 

Volume 

[m 3 x 10 3 (in. 3 )] 

CPU 

1 

9.07 (20) 

40 

6. 55 (400) 

IOP 

1 

22.68 (50) 

60 

13.11 (800) 

Main Memory (32K) 

1 

36.29 (80) 

100 

23.60 (1440) 

Aux Memory ( 500K-word drum) 

1 

31.75 (70) 

390 

46.46 (2835) 

CIU 

1 

11,34 (25) 

25 

6.39 (390) 

DIU 

10 

31.75 (70) 

170 

50. 70 (3094) 

DECU 

1 

6.80 (15) 

37 

14. 26 (870) 

C&D 

1 

317. 51 (700) 

800 

979.95 (59 800) 

Video Recorder 

1 

45.36 (100) 

600 

100. 88 (6 1 56) 

Experiment Recorder 

2 

90.72 (200) 

560 

127.03 (7752) 

Flight Recorder 

1 

45.36 (100) 

260 

63. 52 (3876) 

Total 

— 

22 

648.64 (1430) 

3002 

1433.26 (87 463) 









4.1.1 Computer Subsystem Functions 


The computer subsystem provides supporting functions, primarily logic 
processing and computations, required by other subsystems and experiments. 
The following are the major functions which are supported by the computer sub- 
system: 

1. Data bus subsystem control and operation. 

2. Support of C& D subsystem command and display operations. 

3. Navigation and control law processing for SEPB and CMG. 

4. Onboard checkout. 

5. Sequencing for subsystems. 

6. Control and monitoring for experiments. 



Figure 6. Computer subsystem block diagram. 
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4.1.2 Computer Subsystem Baseline 


The baseline subsystem was selected to provide a sufficiently large, 
general purpose, digital computational capability. This approach was taken 
since the major portion of the DMS costs is for software; therefore, the con- 
cept was selected primarily to minimize software costs. Hardware costs are 
minimal and have been steadily decreasing. 

The software factors considered for cost reduction were ease of pro- 
gramming, sufficient onboard storage, and reduction of verification time. To 
provide this, the computer (l) is a 32-bit machine, providing for quick han- 
dling of large amounts of data; (2) has a floating point capability, which eases 
software programming, especially in scaling required in math oriented pro- 
grams; (3) has mic reprogrammable capability, which allows new instructions 
or small routines to be programmed in the CPU without hardware changes; 
and (4) provides a large main storage capability and an auxiliary storage 
device which reduces the program compaction required for most present space 
vehicle computers. 


The design reference model selected is a centralized computer with a 
modular capability. The central computer provides the processing and main 
storage capability. An IOP provides the specialized function of controlling the 
input and output data flow. It uses the same processor as the centralized 
computer but without the floating point capability. Up to three IO channels may 
be provided to interface with other subsystems or components. The IOP also 
interfaces with the auxiliary memory unit, which provides a mass storage 
capability and allows software programs to be "rolled in and out" of main 
storage as dictated by mission requirements. 

The onboard software is divided into two distinct areas. The first area 
contains the DMS software which encompasses the nonchanging elements of the 
flight software. The second area contains the application software for sub- 
systems and experiments which are, in general, mission dependent. This 
software approach complements the computer subsystem flexibility. 


4#1 - 3 .Computer Subsystem Requirements and Allocations 

A sizing study (see Appendix A) was performed to determine the 
requirements for the computer subsystem. The summary results of that study 
and the capability required for the subsystems and that allocated for experi- 
ments are as follows: 
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1. 32K of 32-bit words of main storage. 

a, 19K for operating system and subsystem application programs. 

b. Approximately 13K allocated for experiment application pro- 
grams. 

2. (TBD) auxiliary storage capability. 

a. 49K for operating system and subsystems. 

b. (TBD) allocated for experiments. 

3. At least 400 KADS. 

a. 180 KADS for operating systems and subsystems. 

b. Approximately 220 KADS allocated for experiments. 

These requirements and allocations provide the basis for establishing the com- 
puter subsystem characteristics. 

As discussed previously, a modular DMS concept was selected that will 
permit the addition of capabilities, as dictated by future requirements. 


4.1.4 Computer (CPU and Main Memory) 

The computer provided for Spacelab applications will be a general pur- 
pose, stored program, digital machine with 32K of 32-bit words of memory 
and with a speed of at least 400 KADS. Other features include floating point 
arithmetic, microprogram capability and compatibility with large commercial 
computers. The major CPU characteristics are summarized below: 

1. Type and Operation: 

a. General purpose stored program, digital. 

b. 32-bit parallel operation. 
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2. Word Length: 


16- or 32-bit instruction and data words, 

3. Performance: 

a. 400 KADS. 

b. Capable of addressing 64K memory. 

c. Fixed and floating point operations. 

4. Programming: 

a. Microprogrammable. 

b. Instruction set adequacy ( TBD). 

5. Interfaces: 

10 P, main storage, and peripherals. 

The main storage unit stores the basic flight program and data used 
frequently by the computer. Based on requirements and other subsystem 
analyses, the main storage unit requirements and characteristics are as follows: 

1* Minimum of 32K of 32- bit words, with 64K address capability. 

2. Random access. 

3. Capable of parity and/or error checking. 

4. Access time of 1 psec or less, 

5. Interface with CPU and IOP. 

Although no specific candidate has been selected for the computer, some 
analyses and comparisons have been performed and are included in Appendix B. 
Section B1 gives operating and physical characteristics of some of the "off-the- 
shelf 1 computers surveyed. Section B2 presents data concerning main and aux- 
iliary memory studies. Candidate computers which appear favorable for 
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Spacelab applications are shown in Appendix B and are in alphabetical order: 
the CDC Alpha- 1, the IBM AP-101 (Shuttle computer) , the Singer SKC-2000, 
and the SUMC/Astronic Breadboard computer. Advanced technology computers, 
such as the SUMC, provide advantages with low power, weight, and volume 
requirements. These computers, however, will require qualification testing. 


4.1.5 Input /Output Processor 

The IOP proposed for Spacelab provides a computer-type I/O processor 
which relieves the computer of many of the IO functions and provides for effi- 
cient IO operations. The IOP includes a CPU which is the same as that used 
in the main computer (without floating point capability) and modular IO chan- 
nels which can handle up to three ClU/data bus systems. In addition, the IOP 
interfaces with the CPU, the main and auxiliary storage units and peripherals, 
as required. The modularity associated with the IOP is discussed in Section 

3. 2. The following is a summary of the IOP requirements and characteristics: 


1. Provide primary control and operation of the data bus. 

2. Have compatible operating characteristics with the CPU. 

3. Be capable of controlling a data bus with 2 Mbs input and 2 Mbs 

output. 


4. Provide a compatible interface with widely used commercial 
computers and peripherals. 

5. Provide time division multiplexed channels for CPU and main 
storage. 

6. Provide read, write, and computer routines to relieve CPU 
communications with I/O peripheral equipment. 


An IOP of the type proposed is currently being designed at MSFC. 


4.1,6 Auxiliary Storage Unit 

The auxiliary storage unit for the computer subsystem has not been 
defined. However, the analysis of requirements (49K for subsystems — see 
Appendix A) and the desire to reduce software development time have 
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established the need for an auxiliary storage device; leading candidates are 
magnetic tape and drum units. Better definition of the storage and access 
speed requirements are needed before the selection of an auxiliary storage 
unit is made. Section B2 presents some of the work and data which have been 
compiled concerning technologies and their applicability for both main and 
auxiliary units. 


4. 2 QMS SOFTWARE AND COMPUTER REQUIREMENTS 

The onboard software is divided into two distinct areas: (1) the DMS 
software, or operating system software, which encompasses the nonchanging 
elements of the flight software, and (2) the application programs software, 
which is that required for subsystem and experiment support and, in general, 
is mission dependent. Sizing studies were performed for both DMS and appli- 
cation software to determine the speed and memory requirements for the 
onboard computer. The Spacelab subsystem application programs have been 
sized in detail, but only preliminary sizing for experiment control and monitor- 
ing functions has been performed. The computer requirements are based on 
these studies. Section Al, gives sizing details for DMS software and the 
application programs for the subsystem. It should be noted that some sub- 
system functions originally included under the subsystem sizing have since 
been included in the operating system software functions but their impact is 
minimal. Section A 2 gives details on preliminary sizing estimates for experi- 
ment application software. 


4.2.1 Onboard Software Concept 

A modular or structured software concept is proposed. This concept 
was selected based on the experience gained on the Saturn and Sky lab pro- 
grams and the reduction it provides in programming and verification time 
required between flights. The portion of the flight software associated with the 
DMS, the operating system, is the heart of the modular concept approach. The 
operating system is a flexible, general purpose program which controls all 
software tasks and scheduling, performs nonchanging services for the appli- 
cation programs, and readily accommodates application program changes. 
Application software modules are controlled by the operating system software 
and are designed for independent operation so that design changes in subsystem 
or experiment application modules do not impact the operation of other modules. 
Figuie 7 illustrates the modular software concept, showing operating system 
primary functions and examples of the application programs. 
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OPERATING SYSTEM 


1. TASK SCHEDULING 

2. C&D SERVICE 

3. MEMORY MANAGEMENT 

4. I/O SERVICES 

5. RESOURCE ALLOCATION 
8. INTERRUPT PROCESSING 
7. TIMING SERVICES 



APPLICATION PROGRAMS 


Figure 7. Spacelab modular software concept. 

The concept also assumes that a higher order language, such as HAL, 
will be used for software, and the computer characteristics are selected to 
accommodate a HOL. For present planning, HAL is assumed to be the HOL 
used for the onboard flight program for Spacelab, and the software sizing 
estimates reflect the use of HOL. 


4. 2. 2 Computer Requirements Summary 

The approach taken in the operating system and application software 
sizing was to divide the Spacelab avionics into subsystems, to determine the 
software functions needed to support each subsystem, and to estimate the soft- 
ware size and speed for each function. The estimates were based on Skylab 
Apollo Telescope Mount digital computer ( ATMDC) , the Saturn instrument 
unit (IU) launch vehicle digital computer (LVDC), Space Shuttle, and concept 
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verification testing (CVT) programming experience. Preliminiary sizing esti- 
mates for the experiments control and monitor functions were made for earth 
observation experiment number EO-04-5, 

A summary of the computer speed and memory requirements is given in 
Table 4. As shown there, a DMS main storage capability of 32K of 32-bit words 
and a speed capability of approximately 400 KADS are required. The auxiliary 
storage capability is (TBD) . Of the 32K storage, 19K is required for the oper- 
ating system and subsystem application programs and approximately 13K is 
available for experiment application programs. Also, 180 KADS speed is 
required for the operating system and subsystems, leaving approximately 220 
KADS for experiments. Details for the DMS software and subsystem application 
programs sizings are given in Section Al and those for experiment application 
programs in Section A2. 


4.2.3 DMS Software 


The DMS, or operating system software, encompasses the executive and 
nonchanging software support functions required to support subsystems and 
experiments. The concept for the DMS software was to provide standardized 
services and capability for a variety of users much as the computer, data bus 
or displays provide their services for users. The operating system includes the 
services provided by a standard executive routine, such as task supervision, 
interrupt processing, and IO and memory access. In addition, the operating 
system includes functions which do not change from flight to flight, such as 
auxiliary memory access, data bus access and C& D services. This approach 
allows a simple, standardized interface for application programs and provides 
a flexible capability which will accommodate a variety of application programs. 


The main function sized for the operating system was the executive, which 
provides task supervision, interrupt processing, I/O control, data bus access, 
and auxiliary storage access. This module controls all other software modules 
as scheduled or as required. Additional items sized for this subsystem were a 
working storage allocation, utility routines (such as sine/cosine and square root, 
which are used by many routines) , and the data bus, C&D and computer self- 
tests. It should be noted that the sizing estimates given in Figure 4 and Appendix 
A do not reflect the split between operating system and application program 
software. However, the software totals do reflect the total computer require- 
ments since these functions are included under their respective subsystems. 
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TABLE 4. DMS SOFTWARE SIZING SUMMARY* 


Storage (Words) 


Main Auxiliary Speed 

( 32- Bit Words) (32-Bit Words) (KADS) 


DMS Software 




Operating System 

2 853 

879 

1.4 

Application Software — Subsystems 




Pointing and Attitude Control 
System 




Navigation and Timing 

1 587 


21.7 

CMG Control 

4 250 


88,9 

SEPB Control 

2 788 


56.6 

Controls and Displays 

3 865 

7 155 

6.9 

Data Acquisition and Distribution 
Electrical Power Distribution 

1 348 

1 500 

3.7 

and Control 

252 



Environmental Control 

282 



Onboard Checkout 

1 050 

39 066 

0. 5 

Structure and Mechanics 

150 



Subsystems Total 

18 425 

48 600 

179.7 

Application Software — Experiments 




Experiment Control and Monitor 
(Experiment EO-04-S, Earth 
Obs. ) 

4 429 


79.6 

Available for Data Processing 

9 146 

TBD 

140.7 

Experiments Total 

13 575 

TBD 

220.3 

Total DMS Capability 

32 000 

TBD 

400 


a. Sizing includes additions for: 

Memory (%] 

Use of HOL 25 

Contingency 25 

Total 50 


)eed /o 




















4.2.4 Application Programs (Subsystem and Experiments) 


Although the application programs are not part of the DMS, a brief 
description of the functions sized for each subsystem and experiment are 
included and these were used as the basis for the computer sizing requirements 
analysis. 


4. 2. 4. 1 Pointing and Attitude Control Subsystem ( PACS) 

The PACS (formerly navigation, stability and control subsystem) soft- 
ware contains the navigation routines and the CMG and SEPB control laws plus 
the monitor and control functions; this subsystem is one of the major drivers 
for the DMS computer requirements. When either the CMGs or SEPB are not 
flown, additional capability is available for experiments. 

The navigation and timing routine provides the calculations necessary to 
maintain knowledge of the vehicle position and attitude. A strapdown reference 
routine uses gyro inputs to calculate the vehicle attitude and to provide attitude 
and attitude rate error for input to the CMG rountines. Vehicle position and 
attitude are periodically updated from the orbiter. Information such as vehicle 
latitude and longitude may be calculated as required for display by the C& D 
subsystem. 

Four advanced Skylab type CMGs are provided for vehicle attitude con- 
trol, The CMG control software provided is illustrated in the functional flow 
diagram (Fig. 8). In operation, the software provides the logic, computations, 
etc. , needed to maneuver the vehicle to a preselected attitude and to maintain 
that attitude for long periods of time. A redundancy management routine is 
provided to switch control logic for CMG malfunctions. 

The SEPB control software, as illustrated in Figure 9, performs strap- 
down computations which compensate for rate gyro drift, calculates SEPB 
attitude, and computes attitude error for control law applications, A slew rou- 
tine is provided to drive the coarse gimbals to the desired position. Both the 
coarse and fine gimbals are used to provide the desired pointing accuracy and 
stability. 
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Figure 8, 


CMG software functional flow, 






MODE CONTROL 


Figure 9. SEPB software functional flow, 









4. 2.4. 2 Controls and Display Subsystem 


The C& D subsystem provides some small processing capability dedicated 
to display operation and duties such as character or vector generation. The 
majority of the data required by the C& D subsystem is stored in, calculated, 
and/or supplied by the main computer. 

The C&D software provides storage, format, and data input control and 
processing for display skeletons (tables). Capability is sized for 20 semi- 
dynamic displays, 5 graphic displays, and an advisory display with 40 entries. 
The skeletons and display formats plus the routines to collect, process, and 
format the data needed to fill in the display formats are provided. It also pro- 
vides the capability for printing preselected advisory messages as required. 

A routine is sized to provide a C&D operational check. 


4. 2. 4, 3 Data Acquisition and Distribution 

The major software impacts for the DA&D subsystem are for command 
processing and data bus operational checks. The command processing routine, 
similar to that performed on Skylab, decodes and executes external commands. 
The data bus operational checks are provided to establish operational readiness 
of the bus and to isolate failures of a DIU, Additional routines provide for data 
bus control and DECU control and status monitoring. 


4. 2. 4. 4 Onboard Checkout 

The onboard checkout software provides storage for display skeletons, 
format tables, and access methods similar to those sized in the C&D sub- 
system. In addition, measurements are monitored and checked during both 
ground checkout and flight to determine any out- of- tolerance condition. When 
malfunctions are noted, a failed data collection routine rapidly collects and 
records up to 40 preselected measurements for later detailed analysis. 


4. 2, 4. 5 Other Subsystems 

Other Spacelab subsystems, such as electrical power distribution and 
control (EPDC), environmental control and life support (ECLS) and structures/ 
mechanics require only minor support, which primarily includes command, 
sequencing, and status measurements collection and processing. 
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4. 2.4. 6 Experiment Software Sizing 

The approach taken for experiment software sizing was to select experi- 
ments characterized by high data rate sensors for which a significant amount 
of data was available and to estimate computer speed and memory requirements. 
Earth observations experiment EO04-S and solar physics experiment SO-Ol-S 
were selected and evaluated; detailed results are shown in Section A2. 


The study results indicate approximately 5K of 32-bit words of storage 
and approximately 80 KADS are adequate for sensor control and monitoring; 
this is well within the computer capability. However, the study also indicates 
that scientific data processing for high experiment data rates exceeds the 
remaining capability allocated for experiments (approximately 9K words and 
140 KADS) ; therefore, only limited scientific data processing should be per- 
formed by the onboard computer. 


4. 3 DATA ACQUISITION AND DISTRIBUTION SUBSYSTEM 

The DA&D subsystem consists of a data bus subsystem, data exchange 
control unit, and tape recorders. The following sections provide the Phase B 
study results for these subsystems/components. 


4.3.1 Data Bus Subsystem 

The primary function of the data bus is to transfer data/commands at a 
high rate between the DMS and other subsystems and experiments. A simpli- 
fied block diagram of the data bus is shown in Figure 10. The data flow on the 
data bus is under the control of the computer/software through the CIU which 
on receipt of instruction from the computer, issues requests for or transmits 
data/commands to a DIU, When a request for data is received by the DIU, it 
collects the data from its subsystem and transmits them to the CIU. If data/ 
commands are received, the DIU will relay these to its subsystem. 

The data bus uses two bus lines, supervisory and reply. The data bus 
transmitter/receiver modules shall be designed to enable the DIU to transmit 
to and receive from the data bus biphase L (Manchester Type II) data at the bit 
rate of 2 Mbs. These modules shall be internal to the DIU and CIU. The data 
bus supervisory and reply lines can be any length from 0 to 152.4 m ( 0 to 500 
ft) of a 50 ohm twisted, shielded pair. The transmitter of the CIU module can 
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Figure 10. Data bus subsystem simplified block diagram 







drive any length of cable up to 154. 2 m ( 500 ft) with a maximum of 32 DIU 
receiver modules connected. The transmitter of the DIU can drive from 0 to 
152.4 m (0 to 500 ft) of cable with up to 31 DIU transmitters and 1 CIU 
receiver connected. The DIU receivers will continuously receive biphase data 
from the supervisory line. The CIU receiver obtains sync and receives data 
within 6 bit times after recognition of a signal on the reply line. 

The two- line data bus was selected for several reasons. The primary 
ones are ease of design, enhanced reliability, and increased efficiency. Use 
of two lines, one for transmit and one for receive, provides isolation between 
the transmitters and receivers. This permits use of a receiver with less 
dynamic range and less sensitivity, thus the transmitter power can be larger. 
Use of two lines also permits current mode coupling for the receivers and 
voltage mode coupling for the transmitters. Reliability is enhanced by allowing 
a DIU to be shutdown if a transmitter fails in the "on" condition. 

The 2-megabit data bus was selected because: (l) it is well within the 
state-of-the-art and (2) increases in bus speed above 2 megabits provide little 
increase in the precentage of experiments that may be accommodated, (See 
Figures 11 and 12). 

The results of a study which established the need for performing limit 
checking at the DIU are reported in Section C3. 


4. 3.1. 1 Data Bus Functional Requirements 

The following is a summary of the data bus functional requirements: 

1. Provide for digital data transfer at a 2 Mbs rate (including over- 
head) on both the supervisory and reply lines. 

2. Provide for computer/software control of the data flow on the data 
bus. This is to permit payload and subsystem changeovers with little or no 
hardware modifications to the DMS. 

3. Provide for a standardized interface between the DMS and the 
experiments and other subsystems, 

4. Provide for modularity and adaptability: (a) the number of DIUs 
used and their locations may be readily changed and (b) capacity of the DIUs 
in number of signals /lines that can be accommodated. 
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TOTAL ACCOMMODATED EXPERIMENT DATA RATE, Mia 



5. Data bus operation is to be asynchronous and messages will vary in 

length* 

6. Capability for data transfers from DIU to DIU will be provided under 
IOP/CIU control. 

7. Provide limit checking at the DIU, 


4. 3, 1.2 Data Interface Units 

The DIU provides the interface between the 2. 0 Mbs biphase L ( Man- 
chester Type H) coded data bus and the user subsystems. The DIU operates on 
a single baseband frequency and responds to a single (programmable) DIU 
address. The DIU has input/output capability (Fig. 13) consisting of discrete 
inputs (DIs), discrete outputs (DOs), analog inputs (AIs), analog outputs 
(AOs), and record in/record outs (Rl/ROs). This capability is modular in 
set increments up to and including the maximum for each type of I/O, The DIU 
modularity is as follows: 

1. DIs 0 to 128 in increments of 16. 

2. ,DOs 0 to 128 in increments of 16. 

3. AIs 0 to 128 in increments of 16. 

4. AOs 0 to 4 in increments of 1. 

5. RI/ROs 0 to 8 in increments of 1, 

In operation, the CIU controls all data bus traffic by commanding which 
DIU is to transmit and what information is required or is to be given. Each 
DIU, after recognizing its unique address, receives and decodes a command to 
perform a specific function. Each DIU controls its DOs, DIs, AOs, AIs, and 
RI/ROs by the channel address contained in the command from the CIU. The 
following is a list of the 16 functions performed by the DIUs, on command. 

Read DIs Write DI monitor control 

Read DI change Write DOs 

Read DI monitor control Read DO status 
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Read AIs 


Read RI 


Read AI limits Write RO 

Read AI out of limits Read Error Status 

Write AI limits Reset 

Write AOs DIU to DIU transfer 

The following paragraphs provide a listing of the characteristics of these inter- 
faces, A simplified block diagram of the DIU is presented in Figure 14, 


DU 


DO* 


Alt 


AOt 


RI/ROt 


NOTES: 

1. MAY BE GROUPED USING ADJACENT Dlt/DOs FOR 
PARALLEL DIGITAL INPUTS/OUTPUTS. 

2. EIGHT BIT RESOLUTION PROVIDED IN ANA LOG -TO- 
DIGITAL AND DIGITAL-TO-ANALOG CONVERTERS. 

3. DATA TRANSFER IS SERIAL AND AT DATA BUS RATE. 

Figure 13, DIU interface. 
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SUPERVISORY LINE 



Figure 14. Data interface unit simplified block diagram. 


1. DI Characteristics: 

a. There are 16 discretes per data bus word, 

b. Discrete groups can be from 2 to 16 adjacent discretes and 
must be in the same word. 

c. Software control to enable/disable scanning DIs for change by 

byte. 
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duration. 


d. Filtering of contact bounce/noise spikes of less than 2 msec 


e. DI high level inputs: 

10 to 32 volts = On or ,f l M 
0 to 1, 3 volts = Off or "0" 

OPEN Line = Off or "0" 

f. DI low level inputs: 

2. 5 to 5 volts = On or ”1" 

0 to 1. 3 volts = Off or ”0” 

OPEN Line = Off or "0" 

g. All DI inputs are protected against unsuppressed inductive loads, 
2, DO Characteristics: 

a. There are 16 discretes per data bus word. 

b. Discrete groups can be from 2 to 16 adjacent discretes and 
must be in the same word. 

c. The computer has the capability of reading DO status, 

d. The status will be correct even when power to external sub- 
systems is off. 

e. DOs will be short-circuit protected in the DIU. 

f. DOs will be maintained at set value until updated. 

g. Source voltage for DOs is supplied by user subsystem. All 
DOs are able to switch the following source voltage and current range: 
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Min voltage = 2. 5 volts 
Max voltage = 32 volts 
Max current = 50 mA 

h. All DOs are protected against driving unsuppressed inductive 

loads. 

3. AO Characteristics: 

a. 0.4 percent accuracy from digital input to analog output. 

b. Short-circuit protection is provided. 

c. Signal level — 0 to 5 volt, 

d. Maximum loading — 2K ohms to ground. 

e. Voltage level is addressed by one 8-bit byte. Byte number 1 
of data word wili be blank, 

f. The computer has the capability to read the analog output status 
on the analog inputs. The four analog outputs are internally connected to cor- 
responding analog inputs (AO^ — AI^ . . . AO^ — AI^). 

g. AOs will be maintained at set value until updated. 

h. AO power source is isolated between DIUs and from other 
internal D1U power. 

4. AI Characteristics: Analog channel input impedances from either 
signal line to chassis ground shall be 10 MI2 resistive, minimum, shunted by 
50 pF capacitance, maximum, at any time and the impedance between these 
signal lines to common signal ground shall be balanced within 20 percent. 

a. AI has 8- bit resolution. 

b. There will be two measurements per bus word (exception: 
read out of limits) . 
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c. There will be a calibration input and it will utilize two analog 

inputs. 

d. There will be an upper limit and a lower limit check for each 

analog. 

e. There will be an indication when an analog is out of limit. 

f. Limit check of analog inputs is initiated when DIU is powered 
on and will continue until DIU is powered off. Limit values will initially be 
minimum and maximum until new values are loaded from the computer. 

g. Analog/digital (A/D) converters with an encoding rate equal to 
or greater than 2 Mbs will be used. The first bit will be the most significant 
one. 


h. The end-to-end 3cr error will be no more than plus- or- minus 
the least significant bit for analog data. (End-to-end is defined as being from 
gate inputs to A/D converter output) . 

i. The Input voltage will be from 0 to 5 Vdc. 

5. RI/RO Characteristics: The RI/RO channel will allow a subsystem 
to send or receive digital data in data bus word format. This channel will have 
the following characteristics: 

a. Serial, variable message length, controlled by word count or 
end of record word. The unique word count of zero will allow transfer of any 
number of words. 

b. Positive response for data transfers will be provided by the 
subsystem on the RI line. The DIU shall maintain a continuous signal on the RO 
lines for subsystem timing and sync. 

c. Subsystem will always be ready to send or receive when 
requested by the DIU. Signal on the clock line shall start and control all trans- 
fers. 


d. 

designated RO, 


There are three twisted, shielded pairs per BI/RO channel 
RI, and clock lines. Shields shall be insulated from each other. 
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e. The RO, RI, and clock lines will have +5. 0 Vdc for a high 
voltage and 0 Vdc for a low voltage. 

f. The RO and clock line drivers shall be able to drive from 0 
to 50 feet of 50 ohm triax cable. 

g. The RI receiver shall be able to recognize a 3. 5 differential 

voltage. 

h. One word (16 bits) will be sent containing error/status infor- 
mation. The DIU shall recognize this word and organize the information in the 
error status word. The last four bits of the error status word will contain 
information from the subsystem, 

i. The source impedance shall be a maximum of 10K ohms. 


4. 3. 1, 3 Computer Interface Unit 

The CIU is the element of the data bus subsystem that controls all traf- 
fic on the data bus. The CIU, under control of the computer/software, will 
perform the following functions: 

1. Format words for the data bus. 

2. Control the transfer of words on the data bus. 

3. Perform serial to parallel conversion on data to computer and par- 
allel to serial conversion on data from computer. 

4. Generate timing and sync for bus. 

5. Check for data bus subsystem errors (parity, etc.) and interface 
errors from the IOP to the CIU. 

6. Store all detected errors for each data bus message and transfer 

to IOP. 

7. Provide the capability for computer controlled self- test. 

8. Total message buffering is not required, only that required for bus 
synchronization. 
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9. Will provide positive response for data transfer between CIU and 
IOP, e. g. , data ready, data received. 

10. For DIU to DIU transfers, the CIU will control the transfer and 
present the received data to the IOP. 

11. Provide for serial data outputs to the DECU for recording and/or 
to the Orbiter communications subsystem for transmission. 

The major elements of the CIU and its interfaces are shown in Figure 15. 
In operation, the command sequence is received from the IOP (or from the CIU 
test fixture during off line operation) . The command sequence starts with an 
A- word (command) and is always followed by a WC-word (word count) . Dur- 
ing write operations, the A-word, WC-word sequence will be followed by D- 
words (data) . Blank words are used to maintain a continuous signal on the 
supervisory line for DIU synchronization and timing. Blank words are allowed 
to exist within a message but not between the A- and WC-word. D- words and 
blanks can be interleaved with up to five continuous blanks allowed between D- 
words. Six continuous blanks within a message shall be considered as a mes- 
sage error. 

A data word consists of a word sync bit (W g ), 2 bus code bits (C t , C 2 ), 

16 information bits, and a parity bit, for a total of 20 bits per word. Figure 16 
defines the makeup of each type of bus word. 


4. 3. 1. 4 Orbiter I/O Buffer 

A buffer is provided to eliminate any synchronization requirements for 
the transfer of data between the Orbiter and Spacelab data management systems. 
It also provides isolation between the two systems. 


4.3.2 Data Exchange Control Unit 

The DECU provides the logic and switching for routing data streams as 
commanded from the C&D or by uplink commands. The data streams (experi- 
ment data, TV, measurements, etc.) input terminals are fixed to the DECU. 
The DECU routes these data streams to selected output terminals which are 
connected to the several recorders and the Orbiter transmitter channels. 
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Figure 15. Computer interface unit simplified block diagram 
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Figure 16. Data bus word formats. 

The DECU, illustrated in Figure 17, consists of control, 20 x 20 switch 
matrix, and monitor units. Characteristics of these three units are as follows: 

1. Control: 

a. Each switch point is addressed and controlled individually, 
b* 11-bit parallel input control signal provided, 
c. Control is transistor- transistor- logic (TTL) compatible. 
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Figure 17. Data exchange control unit. 

2. Switching: 

a. Activation time is 1 msec. 

b. VSWR is 1.25:1 at 60 MHz nominal. 

c. Maximum switch current is 0. 5 A noninductive. 

d. Open isolation: 75 dB at 60 MHz 

87 dB at 1 5 MHz 
99 dB at 3. 5 MHz 
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e, Closed contact resistance is 250 mfi 


f. Contact bounce damped within 0.3 msec. 

3. Monitoring: 

a. Monitor will provide, on request, a serial data stream orga- 
nized into 16- bit words to provide status of each switch. 

b. The monitor will require one DIU Rl/RO channel. 

c. Monitor is TTL compatible. 


4. 3. 3 Tape Recorders 

Onboard storage of data is required and the extent of it is dependent 
primarily on: 

1. Availability and utilization of the TDRS system by the Orbiter com- 
munication subsystem. The TDRS system permits nearly continuous trans- 
mission to ground. 

2. Rates and volume of data requiring collection and storage by the 
many experiments. 

The rates and volumes of experiment data required to be collected are 
illustrated in Figure 18 for digital data and in Figure 19 for TV and analog 
data. To support this data collection and storage requirement, four magnetic 
tape recorders are to be provided, as needed. They are grouped here by type 
of function. Characteristics of each type are as follows: 

1, Experiment Data 

a. Digital/Analog: 

Manufacturer and type 
Tape width and tracks 
Record rate 
Record time 


Ampex AR1700 (modified) 
0.0254 m (1 in. ) with 42 tracks 
1 . 4 Mbs per channel 
30 min per 0. 3556 m (14 in. ) 
reel at max rate 
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RATE M DURATION (hr/day) TOTAL (biti/day) 



SP-14 














Analog Data 
Power 
Tape weight 

b. Video: 


1 MHz per channel 
260 watts 

4. 90 kg ( 10. 8 lb) per reel 


Manufacturer and type 
Tape width and channels 

Record time 


Response 
Power 
Tape weight 

c. Near Real-Time: 


Ampex 550A (modified) 

0.0508 m (2 in.); two color or 
two black and white 
1 channel for 36 min or both 
channels for 18 min per 0. 2032 m 
( 8 in. ) reel 
5 MHz 
600 watts 

4. 76 kg (10. 5 lb) per reel 


Same as the digital/analog recorder described in la above 
except with playback at higher rate. 


2. Housekeeping Data 
Same as la above. 


4.4 CONTROL AND DISPLAY SUBSYSTEM 

The C&D subsystem design reference model was selected to provide a 
flexible, multipurpose control and display capability while providing optimum 
space, equipment, and capability for two crewmen working simultaneously. It 
provides the onboard capability to minitor and control the Spacelab subsystems 
as well as the capability to operate and monitor experiment operation at a 
centralized location. The C& D subsystem provides this flexible core capability 
for use by all experiments with provisions for unique experiment- dedicated 
C& D as required. 

The onboard C&D required for Spacelab includes the Support Module 
C&D console located in the Spacelab and some additional preentry C&D located 
in tlie Shuttle Orbiter. The preentry C&D provides the capability for monitor- 
ing and operating the Spacelab prior to the crew’s entry into the Spacelab 
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habitable area. Appendix D gives a discussion of these two items. Also 
included in that appendix is a discussion of the Pallet- Only C& D concept, used 
only when a Support Module is not flown and when C&D capability is required 
for the experiments located on the pallet. 


4.4.1 C&D Subsystem Concept 

The concept for design of the C& D subsystem was selected to provide 
multifunction controls and displays which can be used for a wide variety of sub- 
system and experiment applications. Other multipurpose controls and displays, 
such as hand controllers and timers, are added for functions not handled by the 
multifunction displays. For this concept, the computer subsystem provides sup- 
port for displays. The computer stores formats and data and provides data to 
display. In addition, it processes C&D inputs as required. This concept, 
therefore, allows a flexible, high capability C&D subsystem by utilizing the 
computational capability available from the onboard computer subsystem and 
the data acquisition and distribution capability provided by the data bus concept. 


4.4.2 Support Module C& D Subsystem 

The Support Module C&D subsystem provides onboard control and dis- 
play capability for Spacelab subsystems and experiments, and it provides the 
the central control of the subsystems and experiments during on-orbit oper- 
ations. The Support Module C&D console (Fig, 20) provides the capability 
for independent operation by two Spacelab crewmen simultaneously. This con- 
sole interfaces with the computer, other subsystems, and experiments via the 
DMS data bus (see Figure 21) . Limited hardwire connections are provided for 
certain critical starting functions ( such as those which must function when the 
DMS is not fully activated) and for special experiment signals which do not 
readily lend themselves to data bus transmission. 


4.4, 2. 1 Multifunction Display System 

Two multifunction display systems will be provided, one for each 
operator, in the console. Each consists of two CRT indicator units, one alpha- 
numeric keyboard, and one multifunction display symbol generator (MFDSG). 
Each multifunction display system provides the capability for independent 
display of computer generated alphanumeric and graphic data as well as video 
information. 
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2. DIGITAL READOUTS 

3. SUBSYSTEM CIRCUIT BREAKERS 
AND DEDICATED C&D 

4. VIDEO MONITORS 

5. MULTIFUNCTION CRT 

6. CAUTION & WARNING 

7. EVENT TIME 

8. MISSION TIME 

9. EXPERIMENT DEDICATED C&D 

10. SUBSYSTEM ADVISORY DISPLAY 

11. AUDIO CONTROL CENTER 

12. VIDEO CONTROL CENTER 

13. CAUTION & WARNING INHIBIT 

14. ALPHANUMERIC KEYBOARD 

15. HAND CONTROLLER 


Figure 20. Support Module C& D console. 
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DATA BUS DATA BUS 



Figure 21* Support Module C& D console block diagram 





Each CRT indicator unit consists of a 0.356 m (14 in.) CRT with the 
capability to permit both high resolution raster scan and stroke write display. 

It is capable of operating in stroke write only, raster scan only, or combina- 
tion stroke write- raster scan display modes. Stroke write beam control sig- 
nal will be received from the DCU. A 1024 scan line video signal with sync 
will be received from a video switching unit. The two CRT indicator units 
within a multifunction display system can be operated in the following modes: 

1, One video and one computer-generated display. 

2. Both video displays. 

3* One video and one combined computer- gene rated and video display. 

The capability to display computer-generated data on both CRTs simultaneously 
from a single display symbol generator is not provided. 

The alphanumeric keyboard provides alpha, numeric, and special editing 
control keys. The alpha and numeric keys are arranged in a standard typewriter 
format, and the editing control keys are arranged in a 3 x 4 key format. Infor- 
mation manually entered on the keyboard is displayed on the CRT before it is 
entered to the DMS computer and selective editing of any character is provided. 

The multifunction display symbol generator accepts a digital data stream 
from the DIU and provides stroke write X and Y deflection and unblanking sig- 
nals to a CRT indicator unit. Only one CRT indicator unit is driven at a time 
by the MFDSG. The MFDSG stores the data instructions received from the DIU 
in its random access memory (RAM) and generates vectors, circles and 8-bit 
ASCII code alphanumeric characters for stroke write CRT display. Display 
refresh is accomplished by redrawing the display format from instructions 
stored in the RAM at a sufficient rate to eliminate flicker. The MFDSG also 
provides the interface circuitry between alphanumeric keyboard and the DIU, 
plus the circuitry necessary for the display and editing of data entered on the 
keyboard before it is transmitted to the DIU. 


4.4. 2. 2 Video Switching Unit 

Two video switching units, one for each crewman, are provided in the 
Support Module C&D console. A single video switching unit switches all closed 
circuit television (CCTV) channels, experiment video channels, and the 
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microfilm converter output to the CRT indicator units, as shown in Figure 21, 
The video switching unit is manually controlled by the crewman and will not 
interface with a DIU, 


4, 4. 2, 3 Microfilm- to- Video Converter 

Two micro film- to- video converters, one for each crewman, are pro- 
vided by the Support Module C&D console. This unit converts imagery stored 
on cassette microfilm to a 1024 scan line TV video signal for display on the 
CRT indicator units. The microfilm- to- video converter can be manually con- 
trolled by the crew or automatically controlled by the central processor via 
the data bus /DIU, 


4. 4, 2.4 Hand Controller 

Two 3- axis hand controllers, one for each operator, are provided. The 
hand controllers are used for pointing CCTV cameras, experiment telescopes 
and cameras, SEPB positioning, and vehicle attitude control (through CMG 
attitude control system) , Backup manual pointing commands are provided by 
alphanumeric keyboard entry. The hand controller will be a stiff stick type 
and will require three DIU analog channels with at least an 8-bit A/D converter 
resolution. 


4.4, 2. 5 Caution and Warning 

The Support Module C&D console provides a C&W display panel for 
critical subsystem and experiment functions. These indicators are hardwired 
to their associated sensors and to the Orbiter C&W. 


4.4. 2. 6 Advisory Display Panel 

The advisory display is a computer driven alphanumeric display which 
provides the crewman with visual low-priority malfunction and operational 
instruction queues. The advisory display has a digital interface with the DIU. 
A plasma 256-character, self- scan panel is the most likely off-the-shelf hard- 
ware candidate for this function. 
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4.4. 2. 7 Time Display Unit 


The time display unit provides the crew with a readout of mission time 
and a manually controllable countup- count event timer. 


4.4,2, 8 Audio Center 

The audio center provides the central controls for the Spacelab audio 
intercom systems. The intercom network will be hardwired to the various 
input/output stations. 


4.4. 2. 9 Dedicated Subsystem C&D 

Dedicated C&D is provided for the Spacelab subsystem, as shown on 
Figure 20, and will primarily be connected to its associated subsystem via 
the DIU/data bus. Selected critical and initial activation functions are hard- 
wired. 


4.4.2.10 Dedicated Experiment C&D 

Approximately 0.441 m 2 (684 in. *) of panel space is reserved for 
experiment- supplied, dedicated C&D panels. This equipment will also be 
connected to its associated experiment equipment via the DIU/data bus. A 
standard hardwire interface capability will, however, be provided to both the 
pallet and experiment module. This includes coaxial cables for high frequency 
signals for oscilloscope display. The display of analog waveforms not suitable 
for multifunction CRT or video monitor display will be accomplished by 
experiment- supplied oscilloscopes, pen recorders, or other such waveform 
display equipment. 


4,4. 3 Pallet- Only C&D 

The Pallet- Only C& D console provides the same type capabilities as 
provided by the Support Module C& D console ( refer to Section 4. 4. 1) . The 
Pallet-Only C&D console is, however, configured for only one-man operation 
as shown in Figure 22 and is located in the Orbiter, It includes multifunction 
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8. CAUTION & WARNING 

9. COMPUTER & DATA ACQUISITION C&D 

10. ELECTRICAL POWER SUBSYSTEM DEDICATED C&D 

11. ALPHANUMERIC KEYBOARD 

12. HAND CONTROLLER (3-AXIS) 

13. TAPE RECORDER CONTROLS 

14. (TBD) 

15. CCTV CONTROLS 

16. TIME DISPLAY UNIT 

17. VIDEO SWITCHING 

18. HAND CONTROLLER MODE & ENABLE CONTROLS 

19. AUDIO UNIT 


Figure 22. Pallet-Only C&D console. 
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control and display components for both subsystems and experiment control, 
dedicated C&D components for subsystem control, and space for dedicated, 
experiment- supplied C&D components. Appendix D provides a more detailed 
discussion of the Pallet-Only C&D model and components used are similar to 
those used for the Support Module, summarized in Section 4.4. 2. 


4. 5 ONBOARD CHECKOUT 

Checkout of the Spacelab subsystems and experiments is required in 
each operational phase. Ground checkout of installed subsystems and exper- 
iments is required; systems checkout is required prior to delivery for instal- 
lation in the Shuttle. After installation, a final checkout of interfaces and 
systems is required, and monitoring is required during launch and transport 
to orbit. During orbital operations, subsystems performance must be con- 
tinuously monitored. During the postflight phase, checkout for safing, main- 
tenance, and refurbishment of systems is required. Studies have shown (see 
Appendix E) that onboard checkout should be used to the maximum extent 
practicable, consistent with other requirements and guidelines. 


4,5.1 OBC Requirements 

4. 5, 1. 1 General Requirements and Criteria 

The following provides a list of the general requirements and criteria 
that have been established for the OBC subsystem: 

1. Perform equipment checkout, monitoring, malfunction detection, 
and fault isolation to a level optimized for cost, safety, maintenance, and 
repair requirements. 

2. Onboard checkout will make maximum use of the DMS and sensor 
hardware provided for normal subsystems monitor and control functions, 

3. Primary maintenance will be done on the ground and shall normally 
be limited to ’ ’remove and replace. " 

4. In-flight maintenance will be limited to minor adjustment and 
replacement. 
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4. 5. 1. 2 Functional Requirements 


The functional requirements of the onboard checkout subsystem are: 

1. Test the subsystem and experiment equipment to establish correct- 
ness of operation at both the subsystem and integrated system level. 

2, Collect, process, and evaluate the provided measurements, and 
display the results to determine whether equipment operation is proper or 
faulty. 


3. Monitor and record faults and selected trend data, 

4. Provide data/information needed by the crew to perform redundancy 
management and in-flight maintenance. 


4, 5. 2 Onboard Checkout Subsystem Description 

The OBC subsystem, ( Fig. 23) is implemented in a manner that utilizes 
the DMS and the sensors normally available for subsystems monitor and control 
functions. The DMS (computer, DA&D, and C&D subsystems) have built-in 
self-test capabilities. In operation, the DMS self-tests are first performed to 
establish the operational correctness of the DMS. Then, the DMS is utilized to 
test and/or monitor the other subsystems and experiments. 

During flight operations, the DMS collects and evaluates a preselected 
group of measurements, which, at the request of the crew or operator, may be 
displayed on the C&D display with tutorial data plus a blink bit to readily 
identify any measurement that is out of tolerance. If the measurements are not 
being displayed and a preselected measurement is out of tolerance, an advisory 
message will be printed on the display in an allocated space. 

Additional definition and description of the OBC subsystem is provided 
in Appendix E. 


4.5.3 Subsystems Support Requirements 

Implementation of the OBC subsystem places requirements on the other 
subsystems. The following provides a summary of these requirements. 
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1. The computer DA&D and C&D subsystems must provide built-in 
self- test features, either individually or in combination with each other, 

2, The measurements provided by the subsystems during flight must be 
sufficient for performing in-flight redundancy management and must permit use 
of flight spares, 

3. The measurements provided by the subsystems must provide 
sufficient information to permit fault isolation to the line replaceable unit ■ 
(LRU) level. 

4, The measurements to be recorded must provide sufficient information 
to permit a trend analysis of those LRU items/subsystems whose useful life can 
be predicted through postflight analysis. 


4,5.4 Computer- Software Support 

The computer- software support presently allocated to the OBC subsystem 
is defined in Section 4. 2,4.4 and the computer memory and speed allocated is 
shown in Table 4. 


4. 6 COMMUNICATIONS 

All Spacelab communications to and from the Earth and other vehicles 
are routed through the Shuttle Orbiter communications subsystems. Any 
requirements exceeding the capabilities provided by the Orbiter (none defined 
at this time) will be handled by unique add-on equipment on the Spacelab. The 
typical Orbiter interfaces with the ground are shown in Figure 24, 

The baseline concept assumes that the Orbiter interfaces with both the 
TDRS and the STDN, The basic Spacelab requirements are to be met using the 
Orbiter/TDRS link, with the Orbiter/STDN link providing backup capability. The 
TDRS provides the high data rate capability which meets the Spacelab require- 
ments and allows nearly continuous, real-time transmission capability. The 
Spacelab channel requirements based on the Oribter’ s providing both downlink 
(Orbiter to ground) and uplink (ground to Orbiter) capability through the TDRS 
or STDN are shown in Table 2. 
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GSFC - Goddard Space Flight Center 

STDN - Space Flight Tracking and Data Network 

TDRS - Tracking and Data Relay Satellite 


Figure 24. Communications concept, 




5.0 RELIABILITY 


The reliability analysis that has been performed to date has been at the 
Avionic System level. The objective of the approach used here was to: (1) 
identify subsystem/components with the lower reliabilities, (2) determine where 
redundant components are needed, and (3) identify areas where in-depth studies 
are needed to determine methods for further improvements in the reliability. 


5. 1 GROUND RULES AND ASSUMPTIONS 

In performing this reliability study the following conditions were assumed. 

1. Coverage - 0. 98 — Where coverage is defined as the probability of 
detecting a failure, isolating that failure and successfully switching in a replace- 
ment unit. 

2. XON/XOFF = 4 — Where XON is the predicted failure rate with the 
equipment "on” and operating and \OFF is the failure rate with the equipment 
powered- down, 

3. For a nominal 7- day mission, experiment support equipment is 
operational for 5 days. 

4. Caution and warning subsystem has a reliability of 1. 

5. Experiment hardware not included. 

6. It is assumed that the buffer storage interfaces with the Orbiter and 
the preentry C&D are in the Orbiter, so they are not included. 


5. 2 STUDY RESULTS 

A list of the Avionic System components was compiled and is presented 
in Table 5. Included in this table is the predicted failure rate (X) , operating 
time for a nominal 7-day mission, number required, and the number of spares 
provided for each component. Based on the data presented in this table, the 
Avionic System unreliability was predicted for five different configurations 
and mission durations. The results of these predictions are presented in Fig- 
ure 25. 
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TABLE 5. EQUIPMENT LIST AND FAILURE RATES 


Subsystem/Component 

Failure Rate 
/ 

(V) 

Operating Time 
(days) 

Number 

Required 

DMS 




C omputer/IOP/CIU 

180 

7 

1 

Data Interface Unit 

72 

7 

9 

Data Exchange Control Unit 

45 

7 

1 

Controls and Displays 

18 

7 

2 

Auxiliary Memory 

150 

7 

1 

Recorders 

150 

5 

4 

SEPB 




Rate Gyros (Set) 3- 

138 

5 

1 Set 

Electronics 

25 

5 

1 

Actuators 

17 

5 

1 

Acquisition TV a 

100 

5 

1 

CMG 




Rate Gyros (Set) a 

138 

5 

1 Set 

Electronics 

25 

5 

1 

EPDC 




Fuel Cell and Controls 

500 

7 

1 

Dc-dc Regulators 

20 

7 

1 

Dc-ac Converters a 

15 

7 

1 

Distributors 

5 

7 

3 

Battery Kit 

60 

5 

1 


a. In all reliability runs, it was assumed that these components were duplex 
because the current design reference model containing these components 
show them redundant. 


b. Failures in 10 B hours. 
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UNRELIABILITY x 10' 



RUNS 


RUN 1: SIMPLEX*; 7-DAY MISSION; NO BATTERY 

KIT; INCLUDES SEPB AND CMGs 

RUN 2: SAME AS RUN 1 EXCEPT REDUNDANT DIUs, 

FUEL CELL, TAPE RECORDER (1 SPARE), 
AND CPU/IO 

RUN 3: SAME AS RUN 2 EXCEPT NO SEPB 

RUN 4: SAME AS RUN 2 EXCEPT NO SEPB 

OR CMGs AND WITH 4 BATTERY KITS 

RUN 5: SAME AS RUN 2 EXCEPT FOR 30-DAY 

MISSION 

•EQUIPMENT AS LISTED IN 
TABLE 5 INCLUDING THE 
FOUR ITEMS THAT ARE 
REDUNDANT. 


Figure 25. Spacelab Avionic System unreliability 



A breakdown of the unreliabilities on a component basis is shown in 
Figure 26. Also, the improvement that can be achieved by selective sparing 
is shown for the four most unreliable components. 


5. 3 SUMMARY 

This study has identified the components that contribute most to the 
unreliability of the Avionic System and shows the improvement that can be 
obtained by selective sparing. Additional in-depth studies are needed to define 
and evaluate other approaches, such as component internal redundancy and 
backup operational modes, and to determine extent of the redundancy and/or 
other approaches needed to meet the 30-day mission duration requirement. 
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UNRELIABILITY x 10' 


NOTES: 

1. 7-DAY MISSION 

2. ALL COMPONENTS ARE SIMPLEX EXCEPT 
THOSE MARKED WITH *. 

3. ^ INDICATES EFFECT OF SELECTIVE 
SPARING 

- DIU, 9 SPARES 

- FUEL CELL, 1 SPARE 

- TAPE RECORDER, 1 SPARE 

- CPU/10, 1 SPARE 


NEGLIGIBLE 




Figure 26. Spacelab subsystem/component unreliability 
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A 1.0 COMPUTER-SOFTWARE AND DATA BUS SIZING FOR SUBSYSTEMS 


A 1 . 1 INTRODUCTION AND SCOPE 

This section of Appendix A provides sizing data for the Spacelab data 
management subsystem. The approach taken included: 

1 . Defining those functions to be performed by the onboard digital 
computer in support of the Spacelab subsystems . 

2. Estimating software instructions, and the computer storage and 
speed requirements in performing these functions . 

3. Estimating signal/data flow on the data bus needed in performing 
these functions. 

Since the data presented here are part of the Spacelab Phase B Study, they are 
preliminary . 

Computer-software sizing data for experiments is given in Section A 2. 


A 1 . 2 GROUND RULES AND ASSUMPTIONS 

For the purposes of this Phase B sizing study, the following ground 
rules and assumptions were used. 

1 . Computer — The digital computer used for sizing is a: 

a. 32-bit floating point machine. 

b. Instructions are half words (16 bits) . 

c. All data are full words (32 bits) . 

2. PACS Subsystem — The Pointing and Attitude Control Subsystem 
provides: 

a. Navigation and timing (all missions) . 

b. Vehicle attitude control using 4 CMGs (kit) , 

c. Experiment pointing using an SEPB (kit) . 


??y;0 


a j « • 
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3. C&D Subsystem — The control and display subsystem provides a 
multifunction display system with the following capability: 

a. 20 semidynamic displays with 40 entries per display and 20 
characters per entry. 

b. Five dynamic displays. 

c. 40 advisory messages with 40 characters each, 

4. Onboard Checkout — During the flight operational phases, the on- 
board checkout subsystem consists of a rapid data/information collection capa- 
bility in the event of a fault or failure. During ground checkout phases, the 
onboard checkout subsystem provides primarily for data/information collec- 
tion, displaying this data/ information on the multifunction displays, and 
identifying any failed or out-of-tolerance condition, plus the rapid data/ 
information collection capability. 

5. Computer/Software Sizing — For this sizing study: 

a. No redundancy management or reasonableness testing of data 
are included {except for CMG control) . 

b. Computer memory requirements for ground checkout and those 
functions with expected usage for only a few short time periods during flight 
are assigned to the auxiliary memory. 


A 1 . 3 SUMMARY OF RESULTS 

The results of this computer- software sizing study are illustrated in 
Table A-i. This table provides the estimated storage (main and auxiliary 
memory in 32-bit words) required and the worst-case flight phase operations 
per second (in equivalent adds per second) required. The memory and OPS 
required are broken down for eight Spacelab subsystems. 

The data bus worst-case loading is shown in Table A- 2 for the flight and 
for the ground checkout phases. The data bus loading during ground checkout 
is much larger than during the flight phases because of the measurements 
high sample rates during checkout. 

It should be noted that this sizing includes only the Spacelab subsystems 
functions . No experiment support is included except where that support is 
included in the sizing/definition of the individual subsystems. 
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TABLE A-l. COMPUTER-SOFTWARE SIZING SUMMARY TABLE 


Subsystem 

Memory 

Speed, 

Worst-Case (Adds) 

Main 

Auxiliary 

Computer/Software 

1 

902 


586 

1 060 

PACS 

5 

750 


— 

133 820 

C&D 

2 

576 

4 

770 

5 480 

DA&D 


899 

I 

000 

3 000 c 

EPDC 


168 


— 


ECLS 


188 


— 

— 

Onboard Checkout 


700 

26 

044 b 

402 d 

Structural and Mechanical 


100 


— 

— 

Total 

12 

283 

32 

400 

143 762 

Contingency 

6 141 

16 200 

35 940 

Total a 

18 424 

48 600 

179 702 


a. Allowances for use of HOL included in contingency. 

b. Used primarily during ground checkout. 

c. Does not include data bus control. 

d. Flight phase only. 

TABLE A-2. DATA BUS LOAD — SUBSYSTEMS (WORST-CASE) 


Subsystem/Function 

Data/Info. Per Second 


In 

Out 

Analog 

Digital 

Discrete 

Analog 

Digital 

Discrete 

PACS 

300 

100 

- - • 

260 

3 



C&D 

54 


20 

— 

921 

20 


Measurements (Flight Only) 

340 

— 

339 

— 

1003 

339 


Onboard Checkout (Flight and 








Ground) 

60 


60 


60 

60 


Onboard Checkout (Ground 








Only) 

1055 

— 

1056 

— 

1819 

1055 


Commands 


2 




2 


Total Flight 3 

754 

102 

419 

260 

1987 

421 

3943 

Total Ground Checkout 3 

1410 

102 

1075 

260 

2743 

1075 

6665 


a. Total with 50 percent growth/contingency: 

Flight 5920 

Ground Checkout 9997 
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A 1 . 4 STUDY APPROACH 


The approach taken in the computer -software sizing study was to divide 
the Spacelab into eight operating subsystems (only for convenience in perform- 
ing this study) , identify/assign and define the computer- software functions 
needed to support each subsystem, and "charge" each subsystem for that 
support. Two exceptions to this approach were made: 

1 . Command and Control Function — The command and control func- 
tions for all subsystems were assigned to (i) the C&D subsystem for those 
commands and data originating at the C&D keyboards, and (2) the DA&D sub- 
system for those commands and data received through the command uplink. 

2. Measurements Collection and Processing — The routines for status 
measurements collection and processing for all subsystems were assigned to 
the computer-software and DA&D subsystems. Computer storage require- 
ments needed for identifying and coding the processing needed, and identifying 
sampling rate, test limits, etc. , were charged to the subsystems since charges 
are dependent on the number of measurements and processing provided. 

Additional definitions of these two functions, items 1 and 2, are provided in 
Section Al.5.6. 

In estimating the computer-software requirements , the Saturn IU LVDC 
and Skylab ATMDC flight programs, plus the studies performed to date on 
Space Shuttle and in support of the CVT facility, were heavily drawn upon for 
these estimates. 

The data bus sizing was determined from an actual count of the signal/ 
data and its rate needed to perform the functions listed for supporting the 
subsystems. 


Ai . 5 COMPUTER-SOFTWARE FUNCTIONS AND SIZING 

The following sections define those functions to be performed by the 
onboard digital computer in support of the Spacelab subsystems. The sizing 
data for these functions, per subsystem, is presented in tabular form. 


Ai.5.1 Computer -Software 

The functions and utilities needed for this subsystem and the sizing 
details are shown in Table A -3. The following is a brief description of each 
function and utility: 
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TABLE A-3. COMPUTER-SOFTWARE SUBSYSTEM SIZING DETAILS 


Subsystem/Function 

Instructions 
(16 bits) 

Data 
(32 bits) 

Total Storage 
(32 bit words) 

Repetition 
Rate Per 
Sec 

Speed 

(Equiv. Adds 
Per Sec) 

Executive 

1415 

275 

983 


220 

Common Data (Working 
Storage) 


700 

700 

-- 

-* 

Utility Routines 

292 

31 

177 



Self-Test a 

732 

220 

586 



Status Measurements 
Processing 

60 

12 

42 


840 

Total 

2499 

1238 

2488 


1060 


a. Auxiliary storage. 


i. Executive — The executive control program, composed of sub- 
programs and associated tables, controls the execution of the dedicated pro- 
gram modules, services input commands, and routes control to the appropriate 
routine on a priority basis. The following are included: 



a. 

Task supervision. 


b. 

Interrupt processing. 


c. 

Input-output control. 


d. 

Data bus access method. 


e. 

Auxiliary memory access method. 

2. 

Common Data — This utility provides temporary working storage. 

3. Utility Routines — This utility provides a family of math routines 
(sine/cosine, square root, arctangent, etc.) for utilization by the dedicated 


program modules. 
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4. Self Test — This test function provides essentially the same capa- 
bility as that provided by the Skylab ATMDC. However, no redundancy 
management or switchover capability is included, and the tests are performed 
at a low rate or on-command rather than the once-per-second rate provided 
on Skylab. These tests include: 

a. CPU tests. 

b. Sum check (fixed memory) . 

c. Ripple test (variable memory) . 

d. Transfer register read-compare. 

The executive is sized to support/control the experiment software 
modules. Also, the common data and utility routines are available for sup- 
porting the experiment modules. Detailed sizing data for selected experi- 
ments are provided in Appendix B. 


Al.5.2 Pointing and Attitude Control Subsystem 

The functions performed in support of this subsystem and the sizing 
details for these functions are shown in Table A-4. This PACS is to be 
divided into three operating systems; the following is a description of the 
functions provided in each of the three systems. 

1 . Navigation and Timing 

a. Navigation — The navigation routine performs those calculations 
necessary to determine vehicle position, velocity, and acceleration from math- 
ematical models of the vehicle and of the earth's gravitational field and atmos- 
phere. An orbital time reference using the calculated orbit position is also 
maintained. The Saturn V LVDC orbital coast navigation routine was used as 

a basis for sizing this routine. 

b. Strapdown and Inertial Attitude Processing — The strapdown 
reference routine calculates the vehicle attitude with respect to the reference 
coordinate system. This routine processes the pallet-mounted rate gyro data 
(reads, scales, and compensates for drift and scale factor errors) and 
computes vehicle attitude. This routine also computes the vehicle attitude 
rate error and attitude error for inputs to the CMG control law. 


72 



TABLE A-4. COMPUTER-SOFTWARE SIZING DETAILS - PACS 


Subsystem/Function 

Instructions 
(16 bits) 

Data 
(32 bits) 

Total Storage 
(32 bit words) 

Repetition 
Rate Per Sec 

Speed (Equiv. 
Adds Per Sec) 

Navigation and Timing 







Coast Navigation 
Strapdown and Inertial Attitude 

660 

35 

365 

1 

1 320 

Processing 

900 

50 

500 

10 

16 000 

Initialization, Mode Control, 
and Display Processing 

300 

30 - 

180 

~ 1 

100 

CMG Control 






Mode Logic and Vehicle Maneuver 

900 

mm 

510 

1 

1 800 

Vehicle Attitude Control 

2200 

imm 

1360 

10 

66 000 

Momentum Management 

900 

50 

500 

1 

1 800 

Redundancy Management 

720 

50 

410 

1 

1 500 

SEPB Control 






Slew for Target Acquisition 

900 

1 I 

510 

1 

1 800 

Strapdown Computations 

900 


500 


16 000 

Coarse Gimbal Control 

500 


490 

10 

2 500 

Fine Gimbal Control 

250 


245 

50 

25 000 

Measurements 

240 

60 

180 

— 

— 








Total 


9370 


1065 


5750 


133 820 



























c. Initialization, Mode Control, and Display Processing — The 
navigation and inertial attitude routines described above are initialized and 
periodically updated from the Orbiter. This routine provides this initializa- 
tion and updating capability. Also provided is the capability for computing 
the latitude and longitude of the earth trace and for providing these data to 
the C&D subsystem for display. 

2. CMG Control - A flow diagram of the PACS functions for imple- 
menting CMG control is illustrated in Figure A-l. 

a. Vehicle Maneuver and Mode Logic — Capability is provided for 
using the CMGs to maneuver the vehicle from any existing attitude to a new 
attitude in response to an attitude maneuver command or in response to an 
operating mode change. In the maneuver routine, a desired attitude reference 
and the rate commands for maneuvering to the desired attitude are generated. 
Logic to control the vehicle CMG attitude control operational modes is also 
included in this function. Computer storage and operation time estimates are 
based on Skylab ATMDC flight program values. 

b. Attitude Control — In this function, attitude error and attitude 
rate error (or CMG gimbal angles when in the caging mode of operation) are 
weighted and filtered to calculate desired control torques about each of the 
vehicle axes. These three desired torques and the position of the CMGs (in 
terms of direction cosines) are then used to generate eight CMG gimbal rate 
commands. The following are performed: 

(1) Read CMG direction cosines and construct the correspond- 
ing gimbal angles. 

(2) Make adjustments for three-CMG operation, if a CMG 
failure is detected. 

(3) Generate control torques by weighting and filtering the 
attitude error and rate error from strapdown (or processing gimbal angles 
when in caging mode) . 

(4) Generate desired gimbal angle rate commands by steering 
and rotation laws from control torques and CMG gimbal angles. 

Computer storage and operation time estimates for this function are based on 
Skylab ATMDC flight program values. 
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Figure A-l. CMG software functions flow 






c. Momentum Management — In this function the CMG momentum 
vectors are monitored and used to command maneuvers to keep the CMGs 
desaturated. A time history of the momentum vectors is maintained and, with 
the expected gravity gradient torques, is utilized, during a period of no critical 
pointing experiment activity, to command maneuvers which desaturate the 
CMGs and position the vehicle in the most desirable orientation. Computer 
storage and operation estimates are based on Skylab ATMDC flight program 
values . 


d. Redundancy Management — In this function the orientation of 
the CMGs is monitored, the actual CMG response is compared with the 
expected, and any failed CMG is identified. If a CMG failure is detected, the 
attitude control routine switches to a three-CMG control law. Computer 
storage and operation time estimates are based on Skylab ATMDC flight pro- 
gram values . 

3. SEPB Control — A flow diagram of the PACS functions for imple- 
menting SEPB control is illustrated in Figure A- 2. 

a. Slew for Target Acquisition — Commands for an experimenter, 
either onboard or on the ground, are used to determine a desired attitude 
reference and to generate rate commands which will rotate the SEPB to the 
desired attitude by driving the coarse gimbals through the control law. Also, 
logic to control the SEPB operational modes is included. 

b. Strapdown Computations — Once every intermediate loop 
(0.1 sec) , this routine: 

(1) Compensates for drift and scale factor errors in rate 

gyro data. 

(2) Calculates SEPB attitude with respect to the reference 

system . 

(3) Computes attitude error for the SEPB coarse gimbal 

control law. 

The calculations are updated by the experiment fine guidance sensors when in 
the fine pointing operational mode. 
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Figure A-2. SEPB software functions flow. 






c. Coarse Gimbal Control — This routine generates SEPB coarse 
gimbal angle commands every intermediate loop (0.1 sec) in response to: 

(1) Rate commands from the SEPB maneuver routine or the 
experimenter’s hand controller, and rate feedback from the processed SEPB 
rate gyro readings when in the maneuver operational mode. 

(2) Attitude rate and error feedback from the processed SEPB 
rate gyro readings and SEPB strapdown calculations when in the attitude hold 
or coarse pointing operational modes . 

(3) Coarse gimbal angle error (difference between a com- 
manded coarse gimbal angle and the actual coarse gimbal angle as read by the 
encoders) feedback when in the standby mode. 

(4) Fine gimbal angle feedback when in the fine pointing mode. 

In each mode, the feedback signal (or difference between the command and 
feedback signals) is modified by control gains and filtered for stability to 
generate the desired control torques. These torques are then implemented by 
commanding coarse gimbal angles. Computer requirements were estimated 
by sketching a rough flow chart and assuming fourth -order digital filters. 

d. Fine Gimbal Control — SEPB fine gimbal angle commands are 
generated in finis routine every fast loop (0.02 sec) during the fine pointing 
operational mode in response to attitude rate and error feedback. To produce 
the rate and error signals, the SEPB rate gyros are read, scaled, biased, and 
integrated every fast loop. (When not in the fine pointing mode, the gyros are 
processed every fifth fast loop, i.e. , every 0. i sec.) The attitude error is 
updated every fifth fast loop by the experiment fine guidance sensor. The rate 
and error signals are modified by control gains and filtered for stability to 
generate the desired control torques, which are implemented by commanding 
fine gimbal angles. Computer requirements were estimated by sketching a 
rough flow chart and assuming fourth -order digital filters. 


Ai.5.3 Controls and Displays 

The functions performed in support of the C&D subsystem and sizing 
details for these functions are shown in Table A-5. This C&D subsystem is 
divided into three functional areas and the following provides a description of 
the support provided in each area. 
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TABLE A-5. COMPUTER-SOFTWARE SIZING DETAILS — C&D SUBSYSTEM 


Subsystem/ Function 

Instructions 
(16 bits) 

Data 
(32 bits) 

Total Storage 
( 32 bit words) 

Repetition 
Rate Per Sec 

Speed (Equiv. 
Adds Per Sec) 

Multifunction Displays 


■■ 




Display Skeletons a 

160 

Hi 

4080 



Display Format Table s a 

80 

slip 

440 

— 


Vector Control 

364 


232 

17 

4780 

Input Control 

226 

KbsI 

113 

— 

100 

Display Data Processing 

708 


354 

2 

200 

Display Access Method 

1750 


875 

2 

400 

Advisory Display 

80 

400 

440 

— 

— 

Command Generation and 

920 

42 

502 



Execution 






Status Measurements 

80 

20 

60 

— 

— 

C&D Operational Cheek a 

- 500 

i 

i 

250 

— 

— 

Total 

4868 

4912 

7346 


5480 


a. Auxiliary memory. 


CD 

























1. Multifunction Displays — For the purposes of this sizing study, 
the following ground rules and assumptions were made: 

a . Hardware 

(1) Two CRTs, same capability provided by both CRTs. 

(2) Refresh of CRT performed by display system. 

(3) Vector capability. 

(4) 25 lines by 50 columns on CRTs. 

(5) Five lines (at bottom) used for scratch pad. 

(6) Cursor control input. 

b . Software 

(1) Capability is to be provided for: 

a. 20 semidynamic displays consisting of 2 columns of 
20 entries per column with 20 characters per entry. Data presented will be 
updated at a 2/sec rate. Entries that are out of tolerance (where limit check- 
ing or testing is provided) are provided a blink bit. , 

b. Five graphic displays (vector control), each con- 
sisting of an X, Y plot with ordinate and abscissa identified and scaled, and 
plot of nominal curve. Vector is no larger than fourth-degree ploynominal 
and, for plotting, 50 points updated at 17 times per second is provided. 

(2) Keyboard inputs provided for text selection. 

(3) Five types of unit conversions. 

(4) Advisory display capability for 40 entries at 40 characters 

per entry. 

The computer-software support supplied for this functional area is described 
below: 


a. Display Skeletons — Capability is provided for 20 display 
skeletons (tables) and these are supplied to the C&D processor on request. 
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b. Display Format Tables — This routine provides the data and 
control needed to convert the data to a display format ( 0 to 5 volt range to a 
parameter such as temperature, pressure, speed, etc., and others). 

c. Input Control — This routine decodes C&D display request and 
initiates skeleton and format fetching . 

d. Display Data Processing — This routine fetches data needed for 
the displays and does necessary conversion. The semidynamic displays are 
updated at a two-time s-per -second rate. 

e. Display Access Method — This routine controls all I/O to and 
from the display system, is executed at a predetermined rate for keyboard 
inputs, and controls output data to the CRT to provide total CRT coverage in 
the skeleton. This routine provides processing needed to initiate execution of 
keyboard inputs . Also provided will be a blink bit for all display entries that 
are out of tolerance. 

f. Vector Control — This routine contains both the skeleton and 
the routines for fetching and processing the data needed for insertion into the 
skeletons for the graphic displays. 

g. Advisory Display — This routine provides the capability of 
printing 40 preselected advisory messages with 40 characters on the CRT 
scratch pad. 

2. Command Generation and Execution — This routine executes the 
commands received through the keyboard from the crew . Operation and 
capability is similar to that provided in Skylab . 

3. C&D Operational Check — This routine provides an operational 
check of the C&D subsystem. The following functional checks are included: 

a. Keyboard, command generation and execution. 

b. CRT, test display. 

c. Computer interface, data control and flow to the C&D sub- 
system from the computer. 


81 



Al.5.4 Data Acquisition and Distribution 

The functions performed in support of the DA&D subsystem and sizing 
details for these functions are shown in Table A- 6. The following is a brief 
description of these functions. 

1. Data Bus Control — The data bus control function, on request from 
the central processor, provides those controls, addresses, codes, timing, 
etc. , needed to (1) interrogate and receive selected data/information from a 
CIU and/or (2) alert and transmit data/information to a DIU. Estimates given 
in the tables include: 

a. Error checking and re-execution of the data/information 
transfers, as needed, plus interrupt handling. 

b. Stacking of I/O requests, as needed, to facilitate the interface 
between the data bus and the C PU . 

c. Controlling number and types of data words in a given 
transmission. 

Not included in the estimates are: 

a. Terminal-to-terminal transmissions. 

b. Limit checking data/inf ormation transmitted on the bus. 

c. Scaling or reformatting data. 

d. Addressing or obtaining data from more than one DIU in a given 
transmission. 

Also, the computer speed required for data bus control is not included because 
there was no definition for the number and location of the DIUs and the quantity 
of usable data that may be provided in a given transmission. 

2. Data Bus Operational Check — The data bus operational check 
exercises the data bus under both normal and simulated failed conditions to 
establish (a) operational readiness of the bus, including the error checking 
system, and (b) to isolate failures (where applicable) to a DIU and possibly, 
depending on final designs, to an element of the DIU. 
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TABLE A-6. COMPUTER-SOFTWARE SIZING DETAILS - DA&D SUBSYSTEM 


Function 

Instructions 
(16 bits) 

Data 
(32 bits) 

Total Storage 
(32 bit words) 

Repetition 
Rate Per Sec 

Speed (Equiv. 
Adds Per Sec) 

Data Bus Control 

400 

— 

200 

TBD 

TBD 

Si 

Data Bus Operational Check 

2000 

— 

1000 

— 

— 

DECU Control and Status 

40 

— 

20 

— 

— 

Status Measurements 






Processing 

100 

— 

50 

10 

3000 

Command Processing 

1006 

126 

629 

— 

— 

Total 

3546 

126 

1899 


3000 


a. Auxiliary memory. 




3. DECU Control and Status — The DECU control and status function 
provides the logic and switching for routing data streams as commanded from 
dedicated control switches, C&D keyboard, or by uplink commands. The data 
streams (measurements, TV, etc.) input terminals to the DECU are fixed. 
This function routes these data streams to die selected output terminals which 
are connected to the several recorders and the Orbiter transmitter channels. 

4. Status Measurements Processing — The status measurements 
processing function collects die many measurements, converts tiiese measure- 
ments to a serial format, adds timing/frame synchronization, and provides 
chaining for data transmission or recording. 

5. Command Processing — Command processing, as assigned to the 
DA&D subsystem, is to decode and execute commands from the ground as 
received through the Orbiter communications system. Operation and capability 
is similar to that provided in Skylab. 


A 1 . 5 . 5 Onboard Checkout 


The computer- software sizing details for the onboard checkout sub- 
system are shown in Table A-7. The following provides a brief description 
of the functions provided. 

1. Failed Data Collection — This routine provides the capability, in 
the event of a fault or failed condition, to rapidly collect up to 40 preselected 
measurements. 

2. Monitor-Limit Check — These data, with available routines, 
permit limit checking or testing measurements during ground checkout and 
identifying on the displays if these measurements are out of tolerances. 

The other three items listed on Table A-7 — display skeletons, format 
tables, and access method — have the same functions as those identified in 
Section Ai.5.3 for the C&D subsystem. This added capability is needed to 
handle the volume of data required for ground checkout. 


Ai.5,6 Other Subsystems 

The following functions are provided for the Spacelab subsystems, 
including electrical power distribution and control, environmental control 
and life support, and structures/mechanical: 
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TABLE A-7. COMPUTER -SOFTWARE SIZING DETAILS - ONBOARD CHECKOUT SUBSYSTEM 


Function 

Instructions 
(16 bits) 

Data 
(32 bits) 

Total Storage 
(32 bit words) 

Repetition 
Rate Per Sec 

— - 

Speed (Equiv. 
Adds Per Sec) 

Failure Data Collection 

1400 

— 

700 

3 

402 

Monitor — Limit Check 


1 444 

1 444 

— 

— 

Display Skeletons 

800 

20 000 

20 400 

— 

— 

£L 

Format Tables 

400 

2 000 

2 200 

— 

— 

3» 

Access Method 

4000 

— 

2 000 

— 

— 

Total 

6600 

23 444 

26 744 

3 

402 


a. Auxiliary storage. 



















1. Command and Control — This function provides a predetermined 
set of command and control functions needed for operating the subsystem. 
These command and control functions may be: 

a. Analog, discretes or digital. 

b. Initiated manually from onboard or from the ground, time 
sequenced, or initiated as a result of some monitored function or condition. 

2. Status Measurements — This function provides the capability for 
the collection and processing of a predetermined set of measurements at 
predetermined rates. Processing of these measurements include providing 
the capability for: 

a. Displaying, on request, preselected measurements . 

b. Testing/limit checking preselected measurements. 

c. Providing advisory messages to the crew through the C&D 

subsystem. 

d. Providing frame synchronization and formatting as needed for 
recording or transmitting to ground. 

The routines for implementing the above two functions are charged to 
other subsystems. Charges to the EPDC, EC/LSS, and structures/mechanical 
subsystem are shown in Table A-8 and include only die requirements for 
indexing, routing, and limit checking each of the subsystems measurements. 

An automated fuel cell purge capability for the EPDC subsystem based 
on power usage is provided, as shown in Table A-8. 


Al. 6 DATA BUS SIZING DETAILS 

The following provides a breakdown of the worst-case data/information 
flow on the data bus as summarized in Section A 1.3, Table A-2. 
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TABLE A- 8. COMPUTER-SOFTWARE SIZING DETAILS — EPDC, ECLSS, AND 
STRUCTURES/MECHANICAL SUBSYSTEMS 


Sub sy stem/ Function 

Instructions 
(16 bits) 

Data 
(32 bits) 

Total Storage 
(32 bit words) 

Repetition 
Rate Per Sec 

Speed (Equiv. 
Adds Per Sec) 

EPDC 

Fuel Cell Purge 

40 

5 

25 



Status Measurements 

114 

86 

143 

— 

a 

Total 

154 

91 

168 



Environmental Control 






Status Measurements 

354 

11 

188 

— 

a 

Total 

354 

11 

188 



Structures/Mechanisms 






Status Measurements 

120 

40 

100 

— 

a 

Total 

120 

40 

100 




a. Speed requirements included in the measurements processing module (Table A-3) . 




1. PACS 


a. Data In (to computer) , per second: 



Function 

Rate 

Analog 

Digital 

Discrete 


Rate Gyros (Pallet) 

10 

30 

- 

- 


CMG Gimbal Angles 

10 

120 

- 

— 


Rate Gyro (SEPB) 

50 

150 

- 

— 


SEPB Coarse Gimbal Angles 

10 

- 

30 

- 


SEPB Fine Gimbal Angles 

10 

- 

30 

- 


Position Sensors (2) 

10 

- 

40 

- 




300 

100 


b. 

Data Out, per second: 






Function 

Rate 

Analog 

Digital 

Discrete 


CMG Rate Commands 

10 

80 

- 

- 


SEPB Coarse Gimbal Angles 

10 

30 

- 

- 


SEPB Fine Gimbal Angles 

50 

150 

- 

— 


Display Data 

- 

- 

3 

— 




260 

3 


C& D Subsystem 





a. 

Data In (to computer) , per second: 





Function 

Rate 

Analog 

Digital 

Discrete 


Semidynamic Display 

1 

20 

- 

20 


Dynamic Display 

17 

34 

— 





54 


20 

b. 

Data Out, per second: 






Function 

Rate 

Analog 

Digital 

Discrete 


Semidynamic Display (1) 

1 

- 

20 

20 


Dynamic Display (1) 

17 

- 

881 

— 


Advisory Display 

- 

- 

20 

— 




- 

921 

20 
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3. Onboard Checkout, Flight Phase 3 

a. Data In: 

Function 

Rapid Data Collection 

b. Data Out: 

Function 

Rapid Data Collection 

4. Measurements, Flight Phase 

a. Data In, per second: 

Function 

Status Measurements 
Collection 

Status Measurements 
Collection 

b. Data Out, per second: 

Function 

Measurements Out 
Measurements Out 


Rate Analog Digital 

Discrete 

3 60 

60 

60 

60 


Rate Analog Digital 

Discrete 

3-60 

60 

60 

60 


Rate 

Analog 

Digital 

Discrete 

10 

329 

- 

328 

1/30 

11 

_ 

11 


340 


339 

Rate 

Analog 

Digital 

Discrete 

10 

- 

992 

328 

1/30 

- 

11 

11 


- 

1003 

339 


3. Monitoring for initiating the rapid data collection function is covered under 
measurements for the flight phase. 
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5. Onboard Checkout, Ground Checkout Phase 


a. Data In, per second: 


Function 


Rate Analog Digital Discrete 


Measurements Collection 

2 4 

667 

Measurements Collection 

10 

329 

Rapid Collection 

3 

60 


1056 


667 

328 

60 

1055 


b. Data Out, per second: 

Function 

Measurements Out 5 
Measurements Out 5 
Rapid Collection Out 


Rate Analog Digital Discrete 

2 4 - 667 667 

10 - 1092 328 

3 - 60 60 

1819 1055 


A 1.7 STUDY RESULTS 

Al.7.1 Computer -Software Sizing 

Table A- 9 provides a summary of the computer -software sizing. 
Included in this table are the requirements for each of the eight subsystems. 
A contingency or growth factor of 50 percent for memory requirements and 
25 percent for operations per second was added. 

The PACS requirements shown are worst-case figures. The PACS 
consists of a three-operations system; two (CMGs and SEPB) are identified 
as kits that may be added, as required, to meet mission/experiment require- 
ments. Table A -10 provides a breakdown of this subsystem. 


Al.7.2 Data Bus Sizing 

Table A- 11 provides a summary of the worst-expected case of data bus 
loading for the Spacelab subsystem. Included in the final totals is a 50 percent 
factor for growth or contingency. 


4. Average value. 

5. Available for recording or external processing. 
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TABLE A-9. COMPUTER-SOFTWARE SIZING SUMMARY TABLE 


Subsystem 

Memory 

Speed, 

Worst-Case (Adds) 

Main 

Auxiliary 

Computer/Software 

1 902 

586 

1 060 

PACS 

5 750 

— 

133 820 

C&D 

2 576 

4 770 

5 480 

DA&D 

899 

1 000 

3 000 c 

EPDC 

168 



ECLS 

188 

— 

— 

Onboard Checkout 

700 

26 044 b 

402 d 

Structural and Mechanical 

100 

— 

— 

Total 

12 283 

32 400 

143 762 

Contingency 

6 141 

16 200 

35 940 

Total 3 

18 424 

48 600 

179 702 


a. Allowances for use of HOL included in contingency. 

b. Used primarily during ground checkout. 

c. Does not include data bus control. 

d. Flight phase only. 


TABLE A-10. PACS SUBSYSTEM BREAKDOWN 


Subsystem 

Memory a 

Operations 3 " 

Main 

Auxiliary 

Navigation and Timing 

1045 

- 

17 420 

CMG Control 

2780 

- 

71 100 

SEPB Control 

1925 

- 

45 300 

Total 

5750 

— — 


133 820 


a. No growth or contingency included in this table. 
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TABLE A-li . DATA BUS LOAD - SUBSYSTEMS (WORST-CASE) 



Data/Info. Per Second 



In 

Out 


Subsystem/Function 

Analog 

Digital 

Discrete 

Analog 

Digital 

Discrete 


PACS 

300 

100 



260 

3 

* 


C&D 

54 


20 

— 

921 

20 


Measurements (Flight Only) 
Onboard Checkout (Flight and 

340 

— 

339 

— 

1003 

339 


Ground) 

Onboard Checkout (Ground 

60 


60 

_ . . 

60 

60 


Only) 

1055 


1056 


1819 

1055 


Commands 


2 




2 


Total Flight 1 

754 

102 

419 

260 

1987 

421, 

3943 

Total Ground Checkout 3 

1410 

102 

1075 

260 

2743 

1075 

6665 


a. Total with 50 percent growth/contingency: 

Flight . 5920 

Ground Checkout 9997 


Ai.7.3 Recommendations 

This study has included only the Spacelab subsystems and has been 
performed as part of the Phase B activity. Follow-on activity is needed to: 

1. Size the support requirements for the experiments. This must be 
done prior to determining the onboard computer size and performance 
requirements . 

2. Update the sizing data included in this study as changes are made 
to the subsystems and as additional definition becomes available. 

3. Provide a data bus traffic model after the DIUs and their location 
are defined and a detailed definition of the data bus operation is provided. 


A2.0 COMPUTER-SOFTWARE SIZING FOR EXPERIMENTS 

A 2. 1 INTRODUCTION AND SCOPE 

This section covers the payload/experiment support requirements and 
is a follow-on to Section Al, The approach taken here included: 
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1 . Defining those functions to be performed by die DMS computer in 
support of the payloads/experiments. 

2. Estimating software instructions and the computer storage and 
speed required in performing these functions . 

3. Combining the results here with those of Section Al. 

A 2. 2 GROUND RULES AND ASSUMPTIONS 

For the purpose of this Phase B sizing study, the following ground rules 
and assumptions were used: 

1. Computer — The digital computer used for sizing is a: 

a. 32-bit floating point machine. 

b. Instructions are half words (16 bits) . 

c. All data are full words (32 bits) . 

2. Pointing, Navigation, and Timing — All pointing, navigation, and 
timing data required for experiment support is provided by PACS. 

3. Redundancy — No redundancy is provided and, therefore, no 
redundancy management is sized. 


A 2 . 3 SUMMARY OF RESULTS 

Based on the results given in Section A 1 and those reported in this 
section, the DMS computer should have: 

1. A speed equivalent to about 400 KADS. 

2 . A main memory of 32K of 32-bit words. 

Also, the DMS computer subsystem should have an auxiliary memory with a 
(TBD) capacity. A breakdown of these computer-software sizing require- 
ments are shown in Table A- 12. No onboard experiment data processing is 
included. 
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TABLE A-12. DMS SOFTWARE SIZING SUMMARY 



Storage (Words) 



Main 

Auxiliary 

Speed 


( 32- Bit Words) 

(32- Bit Words) 

\ 

(KADS) 

DMS Software 




Operating System 

2 853 

879 

1.4 

Application Software — Subsystems 




Pointing and Attitude Control 
System 




Navigation and Timing 

1 587 


21.7 

CMG Control 

4 250 


88.9 

SEPB Control 

2 788 


56.6 

Controls and Displays 

3 865 

7 155 

6.9 

Data Acquisition and Distribution 
Electrical Power Distribution 

1 348 

1 500 

3.7 

and Control 

252 



Environmental Control 

282 



Onboard Checkout 

1 050 

39 066 

0. 5 

Structure and Mechanics 

150 



Subsystems Total 

18 425 

48 600 

179.7 

Application Software — Experiments 




Experiment Control and Monitor 
(Experiment EO-04-S, Earth 
Obs.) 

4 429 


79.6 

Available for Data Processing 

9 146 

TBD 

140. 7 

Experiments Total 

13 575 

TBD 

220.3 

Total DMS Capability 

32 000 

TBD 

400 


a. Sizing includes additions for: 

Memory (%) Speed {%) 
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Use of HOL 

Contingency 

Total 


25 

25 

50 


12.5 

12.5 

25.0 



















For payloads having multisensors and high sensor data rates (megabits 
per second range) , two general conclusions were drawn: 

1. Computer -software requirements for control and monitoring of 
experiments are moderate, 

2. Computer -software requirements for sensor data processing have: 

a. Storage requirements that are large but manageable. 

b. Speed requirements that are excessive. 


A 2. 4 STUDY APPROACH 

The approach taken in this section is illustrated in Figure A-3. Experi- 
ments EO-04-S (Earth Observation) and SO-Ol-S (Solar Physics) were 
selected for use as baselines for this sizing study. These two experiments 
were selected as being the drivers for the computer-software sizing because 
of their large experiment data handling requirements. 


A2.5 COMPUTER-SOFTWARE FUNCTIONS AND SIZING 

The two primary areas where the experiments need/require functional 
support from the onboard computer are control and monitor, and scientific 
data processing. Some small experiment support, in the control and monitor 
area, was included in the study reported in Section Ai. These two areas of 
support are discussed in the following sections for two payloads, EO-04-S and 
SO-Oi-S. It is recognized that EO-04-S was recently deleted from the Spacelab 
payloads, after the sizing effort had been completed; however, it has been 
included here because the new Earth Operation payload sizing will probably 
be a subset of EO-04-S. 


A2.5.1 Functional Requirements 

A2. 5. 1. 1 Earth Observation Payload 

The following is a listing of the DMS functional requirements for 
supporting the EO-04-S payload: 
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• BLUE BOOK 
(NEW) 

• SPECIAL 
STUDIES* 

• BLUE BOOK 
(OLD) 

• SKYLAB 

• INTERVIEW MSFC 
EXPERIENCED 
PERSONNEL 

• EXPERIMENT CONTROL 
& MONITORING 

• SCIENTIFIC DATA 
HANDLING 


•IN ADDITION TO SPECIAL DISCIPLINE STUDIES, EACH PAYLOAD LEVEL II DOCUMENT CONTAINS REFERENCES. 


DOCUMENT 
GROUND RULES, 
REFERENCES, & 
ASSUMPTIONS 


Figure A- 3. Study flow 







1. Capable of operating experiments in automatic mode. 

a. Prime stored timeline. 

b. Alternate stored timeline. 

2. Capable of manual override and minor modification of automated 

mode. 

3. Capable of accepting ground commands, such as: 

a. Major alteration of stored timeline. 

b. Alternate target selection. 

4. Provide crew alert for abnormal sensor operation. 

5. Capable of slaving selected sensors to optical tracking telescope. 

6. Capable of accepting navigation and vehicle attitude data from PACS. 

7. Capable of performing trend analysis on selected sensor status 

data. 

8. Capable of performing the following sensor functions: 

a. Deploy. 

b. Unlock. 

c . Initial checkout . 

d . Power up . 

e . Calibrate . 

f. Mode select. 

g. Pointing. 

h . C over r em o ve/replace . 

i. Initiate data collection. 
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j. Terminate data collection. 

k. Power down/off. 


l. Lock. 

m . Stow . 

9. Capable of controlling and performing selected sensor scientific 
data processing. 

10. Provide or assist in providing the crew with briefing material as 
required. 

11. Provide display capability as required. 

12. Provide for voice annotation of data. 

13. Provide timing, position, and attitude correlation with sensor 

data. 

A2.5.2.2 Solar Physics Payload 

The following is a listing of the DMS functional requirements for 
supporting the SO-Ol-S payload: 

1. Capable of operating experiments in automatic mode. 

a. Preflight programmed experiment timeline. 

b . Crew-originated modifications to experiment timeline . 

2. Capable of real-time manual override of automatic mode, such as 
experiment pointing, sample rate, or mode. 

3. Capable of accepting ground commands to: 

a. Modify programmed experiment timeline. 

b. Direct fine pointing experiments. 

4. Provide crew alert for abnormal sensor operation. 
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5. Capable of slaving selected sensors to optical tracking telescope. 

6. Capable of accepting navigation and vehicle attitude data from 

PACS. 

7. Capable of performing trend analysis on selected sensor status 

data. 

8. Capable of accepting onboard solar flare detection data for use in 
pointing experiments . 

9. Capable of performing the following sensor functions: 

a. Deploy, 

b. Unlock. 

c. Initial checkout. 

d . Power up . 

e . Calibrate/focus . 

f. Mode select. 

g. Pointing. 

h. Cover remove/replace . 

i. Initiate data collection. 

j. Terminate data collection. 

k. Power down/off. 

l. Lock. 

m . Stow . 

10. Capable of controlling and performing selected sensor scientific 
data processing. 

11. Provide display capability as required. 
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12. Provide for voice annotation of data. 

13. Provide timing, position, and attitude correlation with sensor data. 

14. Provide or assist in providing the crew with reference material as 
required . 


A2.5.2 Computer-Software Sizing Details 
A2.5.2.1 Earth Observations Payload 

In sizing the computer -software for the Earth Observations payload the 


following 

conditions were used: 

1. 

Multisensor. 

2. 

High data rate ( 100 Mbs) . 

3. 

High pointing accuracy ( 3 arc min) . 

4. 

Nominal 90 min orbital period. 

5. 

Data taken 15 min/orbit. 


The sizing details are presented in tabular form. The sensor-dependent 
sizing details are presented in Table A- 13. A typical software functional flow 
diagram for sensor control is shown in Figure A-4. The experiment control 
and monitor, and the data processing sizing details are shown in Tables A- 14 
and A-15, respectively. The contingency factor shown in the tables is allocated 
as follows: 


Allocation Memory (%) Speed (%) 

Use of HOL 25 12.5 

Growth/contingency 25 12.5 

A summary of the Earth Observations experiment sizing is shown in 
Table A-16. The control and monitoring functions memory and speed require- 
ments are considered to be nominal. However, the computer speed require- 
ment for scientific data handling is excessive and only about 8 percent of the 
data could be processed, assuming a totally dedicated computer. 
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TABLE A- 13. EARTH OBSERVATIONS PAYLOAD SENSOR-DEPENDENT SIZING DETAILS 


Sensor 

Instruction 

(16-bit) 

Data 

(32-bit) 

Total Storage 
(32-bit) 

Speed 

(KADS) 

Tracking Telescope 

161 

34 

114 


Pointable Identification Camera 

94 

6 

53 


Multi spectral Camera System 

476 

24 

262 


High Resolution Multispectral Camera System 

476 

24 

262 


Multiresolution Framing Camera System 

185 

15 

107 

2.8 

High Resolution Wideband (WB) Multispectral Scanner 

148 

60 

134 

2.2 

WB Synthetic Aperture Radar 

105 

15 

67 

1.6 

Laser Altimeter /Scatter ometer 

105 

15 

67 

1.6 

Visible Imaging Spectrometer 

105 

15 

67 

1 . 6 

Infrared (IR) Multispectral Mechanical Scanner 

138 

54 

123 

2.1 

Visible Radiation Polarimeter 

113 

21 

77 

1.7 

Air Pollution Correlation Spectrometer 

162 

66 

147 

2.4 

High Speed Interferometer 

147 

39 

112 

2.2 

Carbon Monoxide Pollution Experiment 

86 

30 

73 

1.2 

Remote Gas Filter Correlation Analyzer 

125 

39 

101 

1.9 

Advanced Limb Radiance Inversion Radiometer 

108 

36 

90 

1.6 

Microwave Radiometer/Scatterometer 

70 

10 

45 


Wide Angle Viewer 

50 

0 

25 


Data Collection System 

100 

0 

50 

1.5 


Total 


1976 


44.1 











m 



Figure A-4, Typical sensor functional flow diagram. 
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TABLE A -14. EARTH OBSERVATIONS PAYLOAD EXPERIMENT CONTROL 

AND MONITORING SIZING DETAILS 



Instructions 

Data 

Storage Total 

Speed 

Function 

(16 bits) 

(32 bits) 

(32 bits) 

(KADS) 

Common 





Navigation and Attitude 

20 

10 

20 

0,3 

Experiment Scheduling-Timeline 

42 (153) b 

59 (87) b 

80 

0.6 

Sensor Pointing 

369 

83 

268 

5.5 

Sensor Slave to Tracking Telescope 

75 

0 

38 

1.1 

Sensor Deploy/Stow 

75 

0 

38 

1.1 

Sensor Abnormal Crew Alert 

150 

50 

125 

2.2 

Ground Command Uplink 

585 

115 

408 

8.8 

Sensor-Dependent 





19 Sensors 

2954 

503 

1976 

44.1 

Subtotal 



2953 

63.7 

Contingency 3, 



1476 

15.9 

Total 



4429 

79.6 


a. Storage — 50 percent; Speed — 25 percent. 

b. Number in parentheses is optional sizing based on target position rather than time. 
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TABLE A-15. EARTH OBSERVATIONS PAYLOAD DATA PROCESSING SIZING DETAILS 3 " 



Modes 

Auxiliary Memory 


Process 

Operating 

Post-Pass 

Instruction 
(16 bits) 

Data 
(32 bits) 

Total 
(32 bits) 

Main Memory 
(32-bit words) 

Data Compression 
{Adaptive Sampling) 



v 

4300 

140 

2 290 

0 

Auto Imaging Signature 
Analysis 

'si 


V 

2600 

250 

1 550 

1 550 

Auto Nonimaging Signature 
Analysis (Threshold Section) 

V 


V 

1500 

360 

1 110 

1 110 

False Color Processing 

'si 


n/ 

1800 

400 

1 300 

1 300 

Briefing Material Control 



<sj 

2250 

120 

1 245 

0 

Post-Pass Data Control 



n/ 

1800 

125 

1 025 

0 

Graphics Processing 



\ / 

4000 

500 

2 500 

0 

Fourier Analysis 



\! 

600 

64 

364 

0 

Autocorrelation 



si 

2200 

300 

1 400 

0 

Subtotal 





12 784 

3 960 

50% Contingency 





6 392 

1 980 

Main Memory Buffer 




— 


15 000 

Total 





19 176 

20 940 


a. Total image buffering not included. 




TABLE A -16. EARTH OBSERVATIONS EXPERIMENT SIZING SUMMARY 



Experiment 
Application Module 

A SL Subsystem 
Application Modules 

Storage 
(32 bits) 

Speed* 3 

(KADS) 

Storage 
(32 bits) 

Speed 

(KADS) 

£L 

Control and Monitoring 

4 429 

79.6 

90 

0.02 

cl 

Scientific Data Handling 





Main Memory 

20 940 

c 

0 

0 

Auxiliary Memory 

19 176 

— 

0 

0 


a. Sizing includes 50 percent contingency for storage and 25 percent 
contingency for speed. 

b. Worst case, assuming all functions performed simultaneously. 

c. <8 percent of data can be processed with a totally dedicated 2 Msec 
add- time machine. 

A2.5.2.2 Solar Physics Payload 

In sizing the computer-software for the solar physics payload the 


following 

conditions were used: 

1 . 

Multisensor. 

2. 

High data rate (12 Mbs) . 

3. 

High pointing accuracy (1 arc sec) . 

4. 

Nominal 90 min orbital period. 

5. 

Data taken 50 min/orbit. 


The sizing details are, again, presented in tabular form. The sensor- 
dependent sizing details are shown in Table A- 17. The experiment control and 
monitoring, and data processing sizing details are shown in Tables A- 18 and 
A- 19, respectively. The sizing tables, again, contain 50 percent memory and 
25 percent speed contingencies. Half of this contingency is allocated for use 
of HOL and the remaining half is for growth. 
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TABLE A-17. SOLAR PHYSICS PAYLOAD SENSOR-DEPENDENT SIZING DETAILS 


Sensor 

Instruction 
(16 bits) 

Data 
(32 bits) 

Total Storage 
(32 bits) 

Speed 

(KADS) 

Externally Oceulated Coronagraph 

189 

50 

145 

2.8 

100 cm Photoheliograph 

189 

50 

145 

2.8 

Ultraviolet (UV) Spectrograph 

165 

45 

128 

2.5 

Extreme UV Spectroheliometer 

180 

48 

138 

2.7 

Spectrometer/Spectroheliograph 

180 

48 

138 

2.7 

Soft X-Ray Spectrometer/Spectroheliograph 

180 

48 

138 

2.7 

Grid -Collimator Acquisition Photometer 

180 

48 

138 

2.7 

Modular Collimator 

180 

48 

138 

2.7 

Solid State Flare Detector 

180 

48 

138 

2.7 

X-Ray Burst Detector 

174 

47 

134 

2.6 

X-Ray /Gamma- Ray Spectrometer 

174 

47 

134 

2.6 

Gamma -Ray Spectrometer 

174 

47 

134 

2.6 

Solar X-Ray Polarimeter 

165 

45 

128 

2.5 

Bragg Reflection Crystal Polarimeter 

165 

45 

128 

2.5 

Solar Neutron Experiment 

174 

47 

134 

2.6 

High Energy Gamma- Ray and Neutron Detector 

174 

47 

134 

2.6 

Solar Gamma -Ray Detector 

180 

48 

138 

2.7 

Soft X-Ray Tele sc ope /Spectrograph 

180 

48 

138 

2.7 

Total 

3183 

854 

2448 

47.7 
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TABLE A -18. SOLAR PHYSICS PAYLOAD EXPERIMENT CONTROL AND MONITORING SIZING DETAILS 



Instruction 

Data 

Storage Total 

Speed 

Function 

( 10 bit) 

(32 bit) 

(32 bit) 

(KADS) 

Common 





Navigation and Attitude 

20 

10 

20 

0.3 

Experiment Scheduling-Timeline 

42 (153) b 

2 (60) b 

23 

0.3 

Sensor Pointing 

369 

83 

268 

5.5 

Sensor Slave to Tracking Telescope 

75 

0 

38 

1.1 

Sensor Deploy/Stow 

75 

0 

38 

1.1 

Sensor Abnormal Crew Alert 

150 

50 

125 

2.2 

Ground Command Uplink 

585 

115 

408 

8.8 

Sensor-Dependent 





18 Sensors 

3183 

854 

2448 

47.7 

Subtotal 



3368 

67.0 

a 

Contingency 



1684 

16.8 

Total 



5052 

83.8 


a. Storage — 50 percent; Speed — 25 percent. 

b. Number in parentheses is optional sizing based on target position rather than time. 


























108 


TABLE A-i 9. SOLAR PHYSICS PAYLOAD (PRELIMINARY) DATA PROCESSING SIZING DETAILS 



" ■ ■" " 

Modes 

Auxiliary Memory 


Process 

Operating 

Post-Pass 

Instruction 
(16 bits) 

Data 
(32 bits) 

Total 
(32 bits) 

Main Memory 
(32-bit words) 

Data Compression 
(Adaptive Sampling) 


si 

4300 

140 

2 290 

0 

Auto Solar Flare Analysis 

si 

si 

1000 

240 

740 

740 

False Color Processing 

s! 

sj 

1800 

400 

1 300 

1 300 

Reference Material Control 


si 

2250 

120 

1 245 

0 

Post-Pass Data Control 


sl 

1800 

125 

1 025 

0 

Graphics Processing 


S ! 

4000 

500 

2 500 

0 

Fourier Analysis 


sj 

600 

64 

364 

0 

Autocorrelation 


sj 

2200 

300 

1 400 

0 

Subtotal 





10 864 

2 040 

50% Contingency 





5 432 

1 020 

Main Memory Buffer 





— 

15 000 

Total 





16 296 

18 060 




A summary of the Solar Physics payload sizing is shown in Table A- 20. 
All requirements sized were considered nominal except the computer speed 
requirement for scientific data handling. For this payload, only about 13 per- 
cent of the scientific data could be processed with a dedicated computer. 


TABLE A- 20. SOLAR PHYSICS PAYLOAD 
EXPERIMENT SIZING SUMMARY 



Experiment 
Application Module 


Storage 
(32 bits) 

Speed* 3 

(KADS) 

ci 

Control and Monitoring 

5 052 

83.3 

a 

Scientific Data Handling 



Main Memory 

18 060 

c 

Auxiliary Memory 

16 296 

— 


a. Sizing includes 50 percent contingency for storage and 
25 percent contingency for speed. 

b. Worst case, assuming all functions performed simultaneously. 

c. <13 percent of data can be processed with a totally dedicated 
2 Msec add-time machine. 
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APPENDIX B. 


COMPUTER SUBSYSTEM 


PRECEDING PAGE BLANK NOT rP J M f 



Bl. 0 SPACELAB COMPUTER SURVEY 


Bl.l INTRODUCTION 

This appendix presents the results of a survey of "off-the-shelf" com- 
puters to determine their applicability to the Spacelab data management sub- 
system. 

Bl. 2 COMPUTER SELECTION CRITERIA 

The following criteria were used to evaluate the several candidate 
computers: 

1. Flexibility: 

a. Microcoded. 

b. Software compatibility with widely known commercial system. 

c. Interrupt capability and number of priority levels. 

d. I/O operation. 

e. Instruction repertoire. 

2. Computation time* 

3. Floating point hardware. 

4. Memory: 

a. Access time. 

b. Technology. 

c. Expansion capability. 

5. Physical characteristics: 

a. Weight. 

b. Power. 

c. Volume. 
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For this preliminary study, availability and cost data for the candidate com- 
puters were not provided. 


B1.3 SUMMARY 

On the basis of the studies and evaluations performed to date, the 
following computers seem to satisfy the preliminary requirements of Spacelab: 

CDC Alpha- 1 

IBM AP-101 

Singer SKC-2000 

SUMC/ASTR Breadboard 

Reliability was not used as a selection criterion but must receive attention 
before a final selection can be made. Comparison data for these four com- 
puters are given in Table B-l. 


Bl. 4 STUDY RESULTS 


The following is an alphabetical listing of the computers surveyed: 


CDC Alpha-1 
CDC 469 

General Electric GEMIC1 CP32 

IBM 4 Pi TC-1 

IBM 4 Pi TC-2 

IBM 4 Pi CP- 2 

IBM A P-1 

IBM AP-101 

Raytheon RAC-251 

Singer-Kearfott SKC-2000 

Singer- Ke a rfott SKC-3000 

SUMC/DV 

SUMC/ASTR Breadboard 
Univac 1832 


This list is not considered to be complete and as data/ information become 
available on newer or different computers, they should be evaluated. Detailed 
characteristics for each of the computers surveyed are provided in the follow- 
ing paragraphs. 
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TABLE B-l. COMPARISON OF FOUR MOST FAVORABLE COMPUTERS 


Characteristic 

Singer 

SKC-2000 

RCA/SUMC 

CDC 

ALPHA- 1 

IBM 

AP-101 

CPU 

General Purpose 

General Purpose 

General Purpose 

General Purpose 

Type 

Organization Word Length 

Parallel 16 or 32 bits 

Parallel 32 bits 

Parallel 32 bits 

Parallel 16 or 32 bits 

Memory Cycle Time, jusec 

1 

1 

1 

0.9 

Memory Increment 

8K (32 bits) 



8K (36 bits) 

Maximum Memory Capacity 

128K 

2 34 (possible) 

128K(64K direct) 

256K 

Number of Instructions 
(Single and Double) 

132 

139 (256 possible) 

184 

148 

Addressing Modes 

Direct, indirect: 
relative, immed- 
iate; short, long 
return to memory 

Direct, indirect; 
relative, immediate; 
short, long 

Direct, indirect; 
stringing; 

short, long; 8-bit bytes 

Base plus displacement, 
indexed, indirect, relative, 
extended, immediate, 
short, long 

Data Format 
Fixed-Point 
Floating-Point 

16/32 bits 

24-bit mantissa, 
8-bit exp. 

16/32 bits 

24-bit mantissa, 
8-bit exp. 

32 bits 

24-bit mantissa, 
8-bit exp. 

16/32 bits 

24/32-bit mantissa, 
7-bit exp. 

Instruction Format 

16 and/or 32 bits 



16/32 bits 

Error Detection/Correction 

Parity 



Parity 

Special Registers 

60 index registers 

16 index and 16 
base registers 

16 file registers 

16 general registers 
8 registers for floating 
point 
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TABLE B-l. (Continued) 



Singer 


CDC 

IBM 

Characteristic 

SKC-2000 

RCA/SUMC 

ALPHA-1 

AP-101 

CPU (Concluded) 





Memory 

LSI memory integral 

LSI memory used to 



with CPU 

implement registers 



Microprogram 

Yes 

Yes 

No 

Yes 

Volume 


1.557 x 10' 3 m 3 
(95 in. 3 ) 

9.514 x 10' 3 m 3 (0.336 ft 3 ) 


Weight 


1.089 kg (2.4 lb) 

11.339 kg (25 lb) 


Power 


10 watts 

120 watts 


Cooling 


Cold plate 

Conduction 


Memory Module 2 





Standard 

8K, 4.572 x 1CT 4 m 


16K, 5.334 x 10* 4 m 

8K (36-bit) 3-wire 


(18 mil), 3-wire, and 
LSI scratch pad 


(21 mil), 3- wire 


Options 

LSI ROM Plated Wire 


Up to 128K 

Up to 25 6K 

Speeds, /usee 





Access Time 





Core 

0.50 


0.50 

0.45 

Plated Wire 

0.50 




LSI 

0.125 




Cycle Time 





Core 

1.00 


1.00 

0.90 

Plated Wire 

1.00 




LSI 

0.25 
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TABLE B-l. (Continued) 


Characteristic 

Singer 

SKC-2000 

RCA/SUMC 

CDC 

ALPHA- 1 

IBM 

AP-10I 

Memory Module (Concluded) 





Special Features 

Independent power monitoring 
for protection against memory 
loss; self-contained-timing and 
control 


4 access channels 

Power transient pro- 
tection, power switching 
option, half-word parity, 
half-word storage protect, 
power sequencing 

Volume 



0.0197 m 3 (0.695 ft 3 ) 

0.0246 m 3 (0.87 ft 3 ) 

Weight 



20.412 kg (45 lb) 

18.144 kg (40 lb) 

Power 



50 (S), 165 (av), 250 W (max) 

29 0W (8K) 

Cooling 

Conduction/cold plate 


Conduction 

Conduction 

I/O Processors^’ 0 





Concept 

32-bit parallel transmission, 
data bus type 




I/O Channels 

61, each can be multiplexed 



Yes 

Program Interrupts 

16 



5 classes, 1 2 levels 

Direct Memory Access 

Yes - block transfers from 
peripheral equipment 



Yes 

Maximum Data Flow 

1M words/sec per bus 
(for 1 jusec memory) 



900 000 half-words/ sec 

Self Test 

Yes 
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TABLE B-l. (Concluded) 


Characteristic 

Singer 

SKC-2000 

RCA/SUMC 

CDC 

ALPHA- 1 

IBM 

AP-101 

I/O Processors (Concluded) 





Computer I/O Channels 4 * 





Serial Channels 

Yes (16/3 2-bit) 

Yes (16/32-bit) 



Parallel Channels 

Yes (16-bit) 

Yes (16-bit) 


Yes (16-bit) 

Incremental 

3 (10 kHz) 

No 



DMA Block Transfer 

Yes - program controlled 

Yes - program controlled 


Yes - externally initiated 

Discrete 

32-bit 

(some) 



A/D-D/A Program Con- 
trolled/DMA Channel 

Yes 

Yes 



Programmable Interval ■: 
Time 

: Yes 

Yes 


Yes 

Multiplex Channels 

Yes 

Yes 


Yes 

Multicomputer Channels 

Yes 

Yes 


Yes 

Peripheral Channels 

Yes 

Yes 


Yes 

Programming Capability 

S/360 

S/360 CDC-3300 


S/360 

Add Time (Fixed) e , Msec 

2.125/1 

3 2 


1.95 

Add Time (Floating) 6 , Msec 

3.50/2.25 

4 3 


2.95 


a. The RCA/SUMC is not tied to a particular memory module. 

b. RCA/SUMC IOP would be another CPU with high speed interface. 

c. ALPHA- 1 IOP not described because of flexibility and tailoring to a specific requirement. 

d. ALPHA- 1 IOP not included. 

e. First number is for core; second number is for LSI. 




COMPUTER SYSTEM: 


Alpha- 1, Control Data Corporation 


Memory Size: 

Data Word Size: 
Instruction Word Size: 
Number of Instructions: 


16K x 32 bits, expandable to 131K 
32/64 bits 
16/32 bits 

184 with hardware trignometic function instructions 
and square root instruction 


Instruction Word Formats: Short 


r ! i ! 

i 

f 

j 

i 


8-bit f portion specifies main operation function 
code 

4-bit j specifies one of 16 file registers for an 
operand reference 

4-bit i specifies one of 16 file registers for an 
accumulator 


Long 



8-bit f specifies main operation code 
4-bit b index file designator 
4-bit i 
16- bit u 


Computation Time (n sec): Add (32 bits) 2 

Add floating point 3 

Add double length floating point 8. 7 

Floating point multiply 9. 7 

Floating point divide 17 

Since/cosine 37 

Vector rotation 40 

Rectangular- to-polar 41 


Design Features: Floating point machine 

8- bit byte oriented 
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Software: 


Interrupt Feature: 


Selected Features: 


Physical Characteristics: 


Off-line software runs on either a Control Data 
3300 or an SDS Sigma 7 computer and is used for 
preparation of on-line software. This includes: 
Assembler (COMPASS), Program Simulator 
(MIMIC), and Paper Tape Generator (CREATE). 

On-line software includes go/no-go tests and 
diagnostics. 

Internal and external. The number, type, and 
priority of external interrupts are functions of the 
1/ O unit or support equipment. 

Address modes: Short, long 

Indirect, indexing 

Search instruction 

Address any 8-bit byte 

Half word 

Sixteen 32-bit file registers 
Trignometric function instructions 
Stringing instructions 

Direct addressing to 64K (expanded capability for 
indirect and indexed addressing) 

Memory Type: DRO core, 1 psec cycle time 

Random Data Rate To or From Memory: 
Approximately 1 Mhz 

Technology: CPU; bipolar MSI and SUHL circuitry 
Memory; core 


CPU: 

Size: 0. 123952 x 0. 193802 x 0.395224 m 
(4.88 x 7.63 x 15.56 in.) 

Volume is 9. 5145 x 10“ 3 m 3 (0. 336 ft 3 ) 

Weight: 11. 3398 kg (25 lb) 

Power: 120 watts 

Memory: 

Size: 0. 257302 x 0. 193802 x 0. 395224 m 
(10.13 x 7.63 x 15.56 in.) 

Volume is 1.968 x 10” 2 m 3 (0.695 ft 3 ) 


120 



Power: 50 watts (standby) 

250 watts (maximum) 
165 watts (average) 


COMPUTER SYSTEM: C DC-4 69 

Memory Size: 8K 1.27 x 10~ 4 m (5 mil wire) x 16 bits, and 

16K 5. 08 x 10“ 5 m (2 mil wire) x 16 bits, expand- 
able to 64K 


Data Word Size: 16 bits 

Instruction Word Size: 16 bits 

Number of Instructions: 42 

Instruction Word Formats: Type I (Memory reference) 


f 

b 

i m 

3 

L 1 L 

4 | 8 

Type II (Register file) 
f = 0 j 

s i 

1 < 1 4 | 

4 | 4 

Type III (Register file) 
f = 0 j 

s = 0 i 

1 i 1 



4 | 4 


Where f 
b 
m 
d 

s 

i 

r 

t 


function code 

index or indirect designator 
base execution address ( 8 bits) 
address of a file register or a sub- 
function code 
subfunction code 
address of a file register 
a 16- bit file register 
index select register (normal mode 
indexing) 
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Computation Time (Msec): 


Design Features: 


Software 


Interrupt Features: 
Selected Features: 


Memory Types: 


Physical Characteristics: 


Add 2. 4 to 6. 0 

Multiply 10.4 or 16. 5 

Divide 30.4 or 38.0 

Fixed point machine 

16-bit byte oriented 

Ultra small size, weight and power 

16-bit parallel data flow 

Fortran Assembler and Simulator run on CDC 
6000/3000 series host computers. Other soft- 
ware packages such as Diagnostic, Library/ 
Utility/Routines, and Self-Assembler are avail- 
able. 

3 levels, internal 
1 level, external 

Direct, Indexed Direct, Page Zero Indirect, and 
Current Page Indirect Addressing Scheme 

Sixteen 16- bit file registers 

Ultra small size, weight and power consumption 

Basic Arithmetic, Diagnostic Routines, and Sim- 
ulator 

Off- and On-line Assemblers 

Intended for military and aerospace applications 

Random access, nonvolatile, NDRO plated wire 
memory 

Optional — MOS RAM/ROM/EROM 

1.6 psec read cycle, 2.4 psec write cycle times 
for 8K-word, 16-bit memory 

p-MOS/LSI CPU and plated wire memory. 

CPU: 8K, 16-bit model 

Size: 0. 127 x 0. 1397 x 0. 254 m 
(5. 0 x 5. 5 x 10. 0 in.) 

Volume is 4. 5307 x 10~ 3 m 3 (0. 16 ft 3 ) 
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Weight: 4. 5359 kg ( 10. 0 lb) 
Power: 14 watts 

Memory; 8K, 16-bit model 

Size: 0. 1016 X 0. 1016 X 0. 508 m 
(4. 0 x 4. 0 x 2. 0 in.) 
Volume is l,0488x 10 3 m 3 
(64 in. 3 ) 

Weight: 0. 9072 kg ( 2. 0 lb) 

Power: 2. 2 watts, operating 


COMPUTER SYSTEM: 
Memory Size: 

Data Word Size: 

Instruction Word Size: 
Number of Instructions: 
Instruction Word Formats: 


GEMIC1 CP32 , General Electric 

8K x 34 bits (plated wire NDRO) 

17 or 34 bits (sign + 15 or 31 bits and a parity 
bit per half word) 

16 or 32 bits (plus parity per half word) 

70 

RR 


1 1 1 1 1 
OP 

■ i I 
A 

~ i — 
00 

X 

RP 

OP 

i i — r 

A 

1 1 

001 


RX 


OP 

A 

100 

X 

“TTI 1 > 1 1 1 | 1 II II | 1 

Y ... 

R* 

OP 

A 

101 


Y 


123 




Computation Time: 

Design Features: 
Interrput Features: 

Selected Features: 

Physical Features: 

COMPUTER SYSTEM: 
Memory Size: 

Data Word Size: 
Instruction Word Size: 
Number of Instructions: 


IC 


OP 

A 

101 

— 

s 

Y 


I 

OP 

A 

111 

X 

s 

Y 



Where RR = register- to- register 
RP = register pointer 
RX = register indexed 
R* = register indirect 
IC - instruction counter 
I = immediate 

A as accumulating general register 
X = indexing general register 

Add = 2. 0 /Ltsec 

Multiply (32 bits) = 8.4 jxsec 

Main Memory Cycle Time - 1 psec 

Fixed point machine 

The GEMIC1 had 32 individually enabled interrupt 
priority levels 

Registers — There are two sets of 16 general 
registers ( 32 bits each) 

Weight = 20.412 kg (45 lb) 

Input Power = 320 watts at 400 Hz 
Volume = 0.01982 m 3 (0.7 ft 3 ) 


4 Pi TC-l, IBM 
8192 x 16 bits 

16 or 32 bits (sign +15 or 31 bits) 
8> 16, or 24 bits 
54 
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Instruction Word Formats: Short 



Computation Time: 


Design Features: 
Interrupt Features: 


Selected Features: 


Short format add - 15/usec 
Short format multiply = 51 ^sec 
Main memory cycle time = 2. 5 psec 

Fixed point machine 

The TC-1 system is designed to allow three exter- 
nal interrupts* The interrupt operation is a single 
priority and does not allow an interrupt on top of 
an interrupt except under program control. 

Registers — There is one 16-bit linkage register 
for branch returns and three 16- bit base registers 
( B1 — ► B3) , and all four registers are located in 
main memory. The A and Q arithmetic registers 
are 16 bits each. 

Storage — There are two 256-half-word special 
data areas (high and low common — the first 512 
memory locations). The operands for indirect 
branches and status word instructions must be 
located within this area. 

Addressing — Instruction addressing is by bytes; 
operand addressing is by bytes to the half-word 
boundary; the base field is in bytes and the dis- 
placement field is in half words. 
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Instructions — There are ten 8-^bit instructions 
capable of accessing operands located from 0 to 15 
half words above the contents of base register 1 , 
twenty- eight 16-bit instructions capable of acces- 
sing operands located 0 to 255 half words above 
the specified base register, and six 24-bit imme- 
diate instructions which contain the operand in the 
last 16 bits of the instruction. 

Capabilities — Decisionmaking capabilities con- 
sist of relative branch ( forward or backward) on 
condition instructions that are based on the 
accumulator contents (plus, minus, UC or 0), 
compare instructions of the accumulator contents 
with an operand for a skip to IC, IC + 2 and IC + 4 
for the accumulator greater than, or less than or 
equal to the operand, respectively, a skip on carry 
and tally. The two indirect branch instructions 
are limited to operands (addresses) located in the 
low 256 half words of common. There are double 
arithmetic shifts only. No indirect shift operations 
are available. The multiply isaiexie^Sl bits 
operation, and the divide is a 31 4 16 = 16 bits 
operation, truncated with the remainder discarded 
and no overflow indication. 


COMPUTER SYSTEM: 
Memory Size: 

Data Word Size: 
Instruction Word Size: 
Number of Instructions: 
Instruction Word Formats: 


4 Pi TC-2 , IBM 
16 384 x 16 bits 

16 or 32 bits (sign +15 or 31 bits) 
16 bits 
51 

Direct Address 


— 1— 1 — 1 — 1 — 1 — 

! 1 1 1 1 1 1 1— | 

OP 1 F 

ADDR 
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Computation Time: 
Design Features: 
Interrupt Features: 


Selected Features: 


Register Address 


— 1 1 . 1 

— J 


1 r 

— 1 1 1 1 'T* 

OP 


1 R 1 


DISP 


Extended Address 


OP 


OPX 


DISP 


Add = 5 ^sec 
Multiply = 20 jusec 


Fixed point machine 

Memory expandable to 65 536 x 16 bits 

The TC-2 system allows interrupts only when the CPU is 
interruptable for the corresponding source. When masked, 
an interrupt remains pending. Interrupts within interrupts 
are permitted, but the first instruction of any interrupt 
routine will always be executed. 

Registers — There are four 16-bit linkage registers 
(L0 -*• L3) for branch returns and four 16-bit base regis- 
ters, and all eight are located in main memory. The A 
and Q arithmetic registers are 16 bits each. 

Storage — There is a 1024-half- word data storage area 
(common) accessible with 16 direct address instructions. 

Instructions — There are 16 instructions capable of acces- 
sing operands from 0 to 255 half words above the contents 
of B4 B7, six branch, status word and register associat- 
ed instructions with operands fixed in the low 256 words of 
common. 


Capabilities — Decisionmaking capabilities consist of 
relative branch ( forward or backward) on condition, com- 
pare and tally instructions. The two branch indirect 
instructions are limited to operands (addresses) located 
in the first 256 half words of common. Indirect shift 
operations with the shift count in B4 — B7 are available. 
The multiply isal6xl6 = 31 bits operation, and the 
divide is a 31 ? 16 = 16 bits operation, truncated with the 
remainder discarded and no overflow indication. 
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COMPUTER SYSTEM: 


4 Pi CP-2, IBM 


Memory Size: 844 8 x 36 bits 

Data Word Size: 18 or 36 bits (sign +15 or 31 bits and a parity and 

storage protect bit per half word) 

Instruction Word Size: 16 or 32 bits (plus parity and storage protect per 

half word) 

Number of Instructions: 61 


Instruction Word Formats: Half word 



Computation Time: 


Design Features: 
Interrupt Features: 


Selected Features: 


Add = 3. 8 jusec 

Multiply = 11. 5 psec 

Main memory cycle time = 2. 5 psec 

Fixed point machine 

The CP- 2 system has 5 priority interrupt levels 
and 12 interrupt conditions. These include 
external and internal interrupts. Interrupts 
within interrupts are permitted, but the first 
instruction of any interrupt routine will always 
be executed. 

Registers — There are four 16-bit base registers 
where BO is the instruction counter, B1 is a 
hardware register and B2 and B3 are located in 
main memory. There are no linkage registers 
per se. Branch return addresses are stored in 
the branch address and an actual branch is made 
to the branch address plus a half word. The A 
and Q arithmetic registers are 32 bits each. 
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Instructions — There are thirty- one 16-bit instruc- 
tions capable of accessing operands located within 
±128 half words from the contents of BO — ■ B3 and 
twenty- seven 32 bit instructions with the capability 
for direct and single level indirect addressing with 
indexing using B1 — B3. For indirect addressing, 
indexing is performed on the second address. In 
half word operations only the upper half of the 32 
bit- accumulator and a half word memory operand 
are involved. 

Capabilities — The multiply is a 32 x 16 = 64 bits 
or a 32 x 32 = 64 bits operation, and the divide is 
a 64 4- 32 = 32 bits operation, truncated with the 
remainder discarded and overflow set on an improp- 
er divide. Decisionmaking branch instructions are 
a branch on condition, a branch out on condition, 
branch and store IC and skip on condition. Unless 
set to unconditional, all of these decision instruc- 
tions are based on the accumulator contents except 
for a half word branch and store IC instruction 
which is always unconditional. 


COMPUTER SYSTEM: 
Memory Size: 

Data Word Size: 

Instruction Word Size: 
Number of Instructions : 56 

Instruction Word Formats :RR 


AP-1 , IBM 

16 384 x 34 (includes two parity bits per word) 
1 6 or 32 bits 
16 or 32 bits 


' * ' ' 

n-n 



r ■ » | 

| OP 

LmJ 

| 1110 

_0 

Led 


SRS 


i~r 'i » 

n-n 


v 

OP 

LsiJ 

DISP 

62 
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Computation Time: 


Design Features: 
Interrupt Features: 


Selected Features: 


LEX 


till 

OP 


i I I r~ 

1111 bb 

~r~ 

B2 

it rri ii n i i i r i r 
ADDRESS SPECIFICATION 

SSS 





OP 

OPX 

DISP 

B2 

LSS 


i 

OP 

OPX 

DISP 

| B2 

MASK 


Where RE 
SRS 
LEX 
SSS 
LSS 


register-to- register 
short register-to-storage 
long register-to-storage 
short special storage operation 
long storage-to-storage 


RR Add = 1.00 psec 

RE Multiply = 5.75 /x sec 

Main memory cycle time = lpisec 

Fixed point machine 

Memory expandable by 8192 words. 

The AP-1 system has 16 interrupts which are divided 
into 9 levels. The interrupts are executed by use of 
program status words. Each level has two full- word 
locations assigned in main memory. Upon taking an 
interrupt, the computer automatically stores the current 
PSW in the first memory location. It then loads the new 
PSW from the second memory location into the CPU 
status registers. Execution of the interrupt routine 
begins at the address specified by the PSW. 

Registers — There are eight 32-bit multiple use general 
registers. All eight can be used as accumulators or 
index registers and four can be used as base registers 
(BO -*• B3) • Branch return addresses may be stored 
in any of the eight general registers as part of the 
program status word. In addition, the PSW contains 
the instruction counter, condition code, carry overflow, 
wait state and program mask. 
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COMPUTER SYSTEM: 


Memory Size: 


Instructions — There are seventeen 16 bit register 
to register instructions. These instructions operate 
with the eight general purpose registers and do not 
involve memory. There are thirty-three 16-bit 
instructions capable of accessing operands located 
0 to +55 half words from the address specified by 
BO — B3, There are thirty-five 32-bit instructions 
that allow an address field of 16 bits which can be 
used as displacement, immediate data or indexing. 
There are four 16-bit instructions capable of 
accessing operands located 0 to +64 half words from 
the address specified by BO — B3 and 16 bits of all 
1 T s mask bits are implied. Mask bits are used to 
test, set and clear bits in the second operand or 
as a signed 2*s complement 16-bit integer they are 
used to algebracally modify the second operand. 
There are four 32-bit instructions that allow the 
16 mask bits to be individually specified. 

Capabilities — The multiply is a 32 x 32 = 63 bits 
ora 32x 32 = 32 bits operation, and the divide is 
a 64 + 32 - 32 bits operation, truncated with the 
remainder discarded and overflow set on an 
improper divide. The decision instructions, 
branches, are based on the previous setting of 
condition codes by arithmetic and logical instruc- 
tions. There are two condition code bits with three 
defined codes. For the arithmetic instructions, 

CC 0, 1 and 3 indicate =0, >0 and <0, respectively, 
and for the logical instructions, CC 0 and 3 indicate 
the result is =0 and ^0, respectively. 


AP-101, IBM — The AP-101 is a later version of 
the AP-1 and the structure is similar. The new 
and/ or different features are included herein. 

8K x 36 bits (includes a parity bit and a storage 
protect bit per half word). 

Core 

(Expandable in increments of 8K to 32K). 
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Data Word Size: Fixed point, 16 and 32 bits, including sign 

Floating point, 32 and 48 bits, including sign ( 7 
bit characteristics, 24- and 32-bit fraction) 

Instruction Word Size: 16 or 32 bits 

Number of Instructions: 148 

Instruction Word Formats: Refer to AP-1 description 

Computation Time: RR fixed point add = 1.05jusec 

RR fixed point multiply = 4. 85 psec 
RR floating point add = 2, 05 psec 
RR floating point multiply = 4. 85 psec 
Main memory cycle time = 0. 900 fisec 

Design Features: Floating pointing machine 

Memory expandable to 262K words with external 

memory unit 

Mic reprogrammable 

Interrupt Features: The priority interrupts are organized into five 

classes, 12 interrupt levels 

Selected Features: Registers — There are two selectable sets of 32- 

bit hardware, fixed-point general registers and 
eight hardware, floating-point registers. 

Physical Features: Weight = 18.144 kg (40 lb) ( 8K main storage, add 

1. 8144 kg (4 lb) per additional 8K) 

Power = 290 watts 

Volume = 0.02464 m 3 (0. 87 ft 3 ) 


COMPUTER SYSTEM: RAC-251 , Raytheon Company 

Memory Size: 4K expandable to 16K 

Can address up to 65K 

Data Word Size: 32 bits 
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Instruction Word Size: 


16 or 32 bits 


Number of Instructions: 123 


Instruction Word Formats: 


Short 

08 14 15 


OP CODE 


SHIFT COUNT 


R1 


Long 

0 8 10 12 13 14 15 31 


OP CODE 

INDEX 

R3 

R/L 

IND. 

R2 

MEMORY ADDRESS 


Computation Times 6 : 


Design Features: 
Software: 


Interrupts: 


Add: 3. 6/l,8psec 
Subtract: 3. 6/1. 8 jusec 
Multiply: 14. 4/13. 3 jusec 
Divide: 27. 0/25. 9 jitsec 

Fixed point machine 

Two assemblers — AUTORAC and S360RAC 
(runs on IBM 360/40 or better) Diagnostics 

Three priority with external interrupts expand- 
able to 252. 


Selected Features: Word length: 16 and 32-bits 

Indexing: 3 registers 

Multilevel indirect addressing optional 
microprogrammed instructions 

1. 2 psec memory cycle memory area 
protect parity checking 

Real-time clock 

(Most of these are special options) 


6. First number is memory access, second is inter- register. 
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Physical Characteristics: 

( excluding power supply) 

COMPUTER SYSTEM: 
Memory Size: 

Data Word Size: 

Instruction Word Size: 
Number of Instructions: 
Instruction Word Formats: 


Memory: DRO main memory, 1.8 nsec cycle time, 
4K, core 

NDRO Bootstrap, 50 nsec access time, 

32 words, semiconductor 

I/O transfer rate: Up to 10 OK words/sec 

Up to 63 I/O devices addressable 
Up to 16 addressable functions 
per device 

T echnology : LSI-TT L 

Size: 0.4826 x 0. 22225 x 0. 6858 m 
(19 x 8. 75 x 27 in.) 

Weight: 19. 051 kg (42 lb) 

Power: 130 watts 


SKC-2000 (AN/AYK-13) Singer, Kearfott Division 

8K x 16 bits 
Expandable to 131K 

Fixed point — 16/32 bits 

Floating point — 24-bit mantissa, 8-bit exponent 

16 and/or 32 bits 

132 

Short 


0 4 

5 6 

8 

9 15 

OP 

LiL 

XI 

MY 


Long 


* 

» 

o 

5 

6 8 

9 12 

15 16 

OP 

LlI 

XI 

X2 

□ 

M 

JIJ 
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Computation Time 7 : 


Design Features: 
Software: 

Interrupt Features: 
Selected Features: 


Where OP = primary operation code 

Bit 5 - long/short designation 

XI = 1st level index register selection 

X2 = 2nd level index register selection 

M = immediate addressing 

I = indirect addressing 

M7, M16 = memory address field 

E = effective address = M + (XI) + (X2) 

H - half word/index select 


Add: 16-bit 2. 125 psec/l p sec 
32-bit 2.125 psec/l psec 
Multiply: 16-bit 4.0 psec/2. 75 psec 
32-bit 6. 0 jusec/4. 75 psec 
Divide: 16- bit 7. 25 psec/5 psec 
32- bit 10. 25 psec/9 psec 
Times given include both instruction and operand 
access. Times shown are baked on the average 
of short instructions. 


Floating point machine 

FOCAP and JOVIAL run on 360/370 Self- test assembler 

16 program interrupts (expandable to 64) 

Address Modes: Short, long, return to memory 
Direct, indirect, relative, 
immediate 

Indexing: 60 total registers in LSI 

7 first level ) 

8 second level j S rou PS 

Direct Memory Access: 16 (2 preassigned) 

I/O Channels: 61 directly addressable 

Data Bus: 32 bit parallel — 4 mHz 

Maximum Data Flow Rate: To memory — ( cycle 

time limited) 

1. 0 psec — 10 6 words/sec 


7. First value given in core memory, second value given in LSI memory. 
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Memory: Asynchronous independent 
1 to 16 modules 
SK x 32 bit size 

Memory Type: Core ( 18 mil DRO) — Standard 
LSI RAM — Standard 
ROM — Optional 
Plated wire — Optional 

Memory Speeds: Access time/cycle time, pisec 
LSI — 0. 25/0. 25 
Core — 0. 50/1. 0 

Technology: CPU, TTL-ICs and MSI 

Memory, Core — Hybrid Circuits 

Physical Characteristics: Size: 0.3886X 0.1905x 0.1245 m 

(15. 3 long x 7. 5 wide x 4. 9 in. high) 
Weight: 8. 936 kg ( 19. 7 lb) 

Power: 245 watts, including regulator loss 


COMPUTER SYSTEM: 
Memory Size: 


Data Word Size: 
Instruction Word Size: 
Number of Instructions: 


SKC-3000, Singer, Kearfott Division 

6144 Word Program ROM ( 1 6 bits) 

512 Word Scratchpad RAM ( 20 bits) 

1024 Word Data/Program ROM (20 bits) 

256 Word Microprogram ROM 
Expandable to 32K with external memory 

19-bit plus parity, optional 16-bit plus parity 

15- bit plus parity 

47 


Instruction Word Formats: Memory Reference 

0 4 5 


14 15 


OP CODE 


ADDRESS 
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Computation Time 8 

Design Features: 
Software: 

Interrupt Feature: 
Selected Features: 


8. First number 


Relative Jump 


0 

4 

5 

6 



14 

OP CODE 

SIGN 

DISPLACEMENT 

Operate 






0 

4 

5 

8 

9 

10 14 

15 

OP CODE 

SECONDARY 

CODE 

I 

SHIFT COUNT 

3 


Subroutine Jump 

0 4 5 14 15 0 14 15 


OP CODE 

ADDRESS FOR 
PROGRAM COUNTER 

P 

JUMP ADDRESS 

P 


Input- Output 

FIRST WORD SECOND WORD 


0 4 

5 6 

14 

15 

OP CODE 

IN 

OUT 

DEVICE CODE 

ill 


: Minimum execution time including memory access 

Add: 5. 8/5. 5 jus ec 
Multiply: 47. 6/38. 5 psec 
Divide: 51. 0/41. 8 jusec 

Fixed point 

Assembler/Loader and Interpretive Simulator run on 
IBM 360/370 computers 

Interrupt on data parity error two -level interrupt 

Microprogrammed MOS LSI CPU and control 
Double Precision 
Addressing: Direct, Indexed 


is for 19 -bit, second number is for 1 6 -bit, 
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Branches : C onditional 

Global/R elati ve 
Direct/Indirect 

Logical 

Input/Output 

Single and Double Register Shift 

Physical Characteristics: Size: 0-127 x 0.1701 x 0.0102 m 

( 5. 0 x 6- 7 x 0.4 in.) ( 1 card CPU/Memory) 
Weight: 0.2313 kg (0. 51 lb) 

Power: 19 watts (4* 5K memory, 19 bits) 

22 watts (7. 5K memory, 19 bits) 

16 bits — lower power 
MTBF: 11 529 hours 


COMPUTER SYSTEM: SUMC/DV 

Memory Size: 2048 x 16 bits 

Data Word Size: 16 bits (sign + 15 bits) 

Instruction Word Size: 16 or 32 bits 

Number of Instructions: 31 


Instruction Word Formats: RR 
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Where 


Computation Time: 


Design Features: 
Interrupt Features: 


Selected Features: 


RR - r egis ter- to- r egis ter 

RX = register-to-indexed main memory 

RS = register- to -main memory 

SI - main memory and immediate operation option 

RX add = 13* 2 psec 

RR add = 8. 8 psec 

RX multiply = 24. 2 psec 

Main memory cycle time - 400 nsec 

Fixed point machine 
Microprogram controlled 

The SUMC/DV system has three priority interrupt levels. 
Each interrupt level has associated with it a number of 
I/O devices and a set of general registers. Each level 
has an assigned priority and operates only if that level 
is the highest requiring service. Interrupts may become 
active by a peripheral device generating an interrupt 
or through the use of the Program Control Instruction. 
Interrupts are executed by storing the current status and 
loading the status of the new interrupt level. 

Registers — There are eight 16-bit general registers that 
can be used as accumulators, index registers and base 
registers. A branch address can be specified by an 
instruction address or it can be obtained from one of the 
general registers. 

Instructions — There are seven 16-bit register-to-register 
instructions that operate with the eight general purpose 
registers. There are fifteen 32-bit registers that are 
capable of accessing operands 0 to +4096 from the base 
plus index registers. There are four 32-bit instructions 
used for shift and load and store operations and five 32 - 
bit instructions that provide an 8-bit immediate operand. 
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Capabilities — The multiply is a 16 x 16 = 32 
bits operation, and the divide isa 32 4-16=16 
+ 16 remainder bits operation. Decisionmaking 
by branch on condition operations can be done 
after the condition code is set by previous 
instructions. The condition code indicates the 
results of most arithmetic and logical instruc- 
tions. For the arithmetic instructions, CC 0, 
1, 2 and 3 indicate « 0, <0, >0 and overflow, 
respectively, and logical instructions used CC 
0 and 1 to indicate results =0 and #0, respec- 
tively. 


COMPUTER SYSTEM: 
Memory Size: 

Data Word Size: 

Instruction Word Size: 
Number of Instructions: 
Instruction Word Formats: 


SUMC/ASTR Breadboard 

2048 x 32 bits 

32 bits ( sign + 31 bits) 

16, 32, or 48 bits 

139 

RR 


TTTTTTT 
OP CODE 

~zr\ 

1 IT 
R2 



RX 





OP CODE 

R1 

X2 

B2 

D2 

RS 





OP CODE 

j R1 

R3 

| B2 

D2 

SI 





OP CODE 

12 

|_B1 

D1 


SS 


OP CODE 

1 L1 ! 

1 L2 

Bl| 

D1 

1 02 1 

HP 

0 7 

11 

15 

19 

31 

35 

" 47 
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Where 


Computation Time: 


Design Features: 


Interrupt Features: 


Selected Features: 


Physical Features: 


BE = register-to-register 

BX = register-to-indexed main memory 

BS = register-to-main memory 

SI = main memory and immediate operation option 

SS = main memory- to- main memory 

BX fixed point add = 3 ^sec 
BR fixed point add = 1*6 nsec 
BR fixed point multiply = 4 jusec 
BR floating point add = 4 Msec 
RR floating point multiply = 8 fjsec 
Main memory cycle time = 400 nsec 

Floating point machine 
Microprogram controlled 

The SUMC interruption system permits the CPU to 
change its state as a result of conditions external to the 
system, in I/O units or in the CPU itself. The five 
classes of these conditions are input/output, program, 
supervisor- call, external, and machine check inter- 
ruptions. 

Register — There are sixteen 32-bit general registers 
that can be used as accumulators, index, or base 
registers. There are four floating point, 64-bit reg- 
isters. There are 32 utility registers used for tem- 
porary or control mask storage. The remainder of the 
64 registers are used for program status indication. 

Instructions: The CBM system 360 instruction set is 
emulated. The standard and floating point instruction 
sets were implemented. 

Weight = 4.535 kg (10 lb) 

Power = 15 watts 

Volume = 0. 0142 m 3 (0. 5 ft 3 ) 
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COMPUTER SYSTEM: 


Univac 1832 


Memory Size: 8192 x 36 bits (expandable to 32K, magnetic film 

core) 

Data Word Size: 36 bits (includes 4 parity control bits) 


Number of Instructions: 134 


Computation Time: 


Design Features: 
Selected Features 


Physical Features: 


Add = 1.5 ^sec 
Multiply » 8 j^sec 

Main memory cycle time = 750 nsec 
Floating point machine 

The Univac 1832 is a multiprocessor configurable, 
airborne computer system. The system permits 
one or two processors, one or two input/output 
controllers, and one to three memory modules. 

For two CPUs, two IOCs and two Memory Modules: 
Weight = 173. 27 kg (382 lb) 

Power - 2300 watts 
Volume = 0.2973 m 3 (10.5 ft 3 ) 


B2.0 SPACELAB DMS MAINFRAME. AUXILIARY MEMORIES, AND 
MASS STORAGE STUDIES 

This section presents the trade-off study results, conclusions, and 
recommendations of memory and storage systems for the Spacelab DMS. These 
resulted from the analysis of current and planned technologies in main memory 
systems and mass storage. 


B2. 1 INTRODUCTION 

The analyses of the main memory systems and mass storage capability 
were made on the basis of performance parameters, physical characteristics, 
environmental susceptibility, technology evaluations, and cost per bit. The 
mass storage was further broken down into three categories, high speed buffer, 
intermediate, and mass storages [l, 2 1 , The appropriate technology for each 
specific area of application was determined and the candidate memory and 
storage systems, which were existing or in the development stage, were 
recommended for consideration. 
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The technologies reviewed vary considerably and represent past and 
recent research and development. Further study should be directed at new 
technologies which will be available. 


B2. 2 DATA STORAGE TECHNOLOGY REVIEW 

Recent developments and future trends in memory system technology 
are discussed in the following paragraphs. Identification of candidate tech- 
nologies and selection of the currently available memory system for each 
specific area of aerospace application will be discussed in the subsequent 
sections. 


B2, 2. 1 Magnetic Tape 

Highly refined magnetic tape system technology has produced the capa- 
bility for processing data that are superior and lower in cost, and have greater 
volume/rate ratio than other current data storage facilities. The major dis- 
advantages of tape recorders stem from the fact that they are electromechanical 
devices, and the wear of the tape, head, and bearings limits the life of a tape 
system. Tape lives of over 10 000 passes have been attained but this would 
still be inadequate for highly used mass storage. Recently, the life of the tape 
system has been improved through the use of new surface lubricants, and the 
head life is now estimated somewhere between 4000 and 5000 hours, depending 
on the application environment. Operating in a hostile environment of rugged 
shock and vibration situations cause errors in record and playback. Motor life 
is another factor which limits the system reliability and life. However, due 
to its extremely low cost per bit, the construction of a trillion (10 12 ) bit tape 
system or a system with capacity greater than 10 14 bits would be feasible. 
Ampex Tearbit Memory and Grumman Masstape systems of extremely high 
capacity have recently become available on the commercial market. The 
systems are capable of storing more than a trillion bits of information — about 
a hundred times more on-line data capacity than conventional disc storage 
systems provide. Other strategies which can achieve the same capacity as 
these two and which utilize multiple-track recording techniques, with the 
number of tape tracks ranging from 28 to 117, have been adapted by RCA, 
Ampex, and others. 
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B2. 2. 2 Ferrite Core 


This is the predominant technology today, accounting for more than 90 
percent of the memories shipped in traditional mainframes outside the IBM 
market. It has been forecast that the core memory may one day be replaced 
by semiconductor memory; however, both are presently enjoying unparalled 
growth. Cheaper and more reliable core memory systems are available 
because of the development of the new core manufacturing technique, the 
automation of core stringing process, and the use of newer materials. Most 
computer manufacturers predict that core memory is expected to remain a 
significant factor in computer memories for the next 10 years or, possibly, 
longer. 


B2. 2. 3 Plated Wire 


This recently pursued variation of thin film technique has not been 
widely accepted by memory manufacturers. Only a few companies have pro- 
duced wire memories because of the lack of strong incentive in competing with 
the other technologies. The reason seems apparent: Plated wire is a more 
expensive technology then semiconductor. Speed, low power, nondestructive 
readout, and the capability of retaining high reliability in a severe operating 
environment give this technology a strong potential for aerospace and military 
applications. 


B2. 2.4 Planar Thin Film 


Planer thin films are similar to plated wire, the difference being that 
in thin film systems the magnetic material is deposited on a flat substrate 
rather than on a wire. Although thin film technology has been recognized for 
a long time because of its high speed and potential for batch fabrication, pro- 
duction difficulties encountered in varying it to improve density, power, and 
noise levels have discouraged widespread use, except in some military 
applications. 


B2. 2. 5 Magnetic Bubble 

The magnetic bubble memory consists of a pattern of cylindrical mag- 
netic domains in thin films of magnetic garnets. Stored information is non- 
volatile if a uniform dc magnetic field is maintained. This new technology. 
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most of which is still in the laboratory stage, offers the prospect of several 
million bits per inch on substrate 6.456 x 10 6 to 6.456 x 10 4 m? (0. 1 in. to 
1. 0 in. 2 ) . The density of bubble device can be expected to increase from the 
present 10 G bits/in. 2 to 10 8 bits/in. 2 . The Bell Laboratories claims that a 1. 5- 
megabit bubble memory is being developed and that it is the first buffle memory 
ever designed for computer applications. The potential of bubble memory will 
not be realized quickly unless its cost per bit can be cheaper than that of a semi- 
conductor memory. However, the industry experts predict that commercial 
bubble memories are still 5 to 10 years away and that the first application will 
be as replacement for fixed-head storage systems. 


B2. 2.6 Domain Tip Projection Logic ( DTPL) 

DTPL is one of several types of metallic magnetic shift registers. 

DTPL has some potential in the area of intermediate storage, but the packing 
density is appreciably less than that achievable with magnetic bubble memories. 
If the magnetic bubble memory does enter production, it is doubtful that DTPL 
will develop into an inexpensive storage. 


B2. 2. 7 Magnetic Acoustic 

These systems utilize an acoustical wave in a quartz substrate to 
distore a layer of magnetic- strictive thin film deposited on it. The acoustic 
wave is used to scan the memory strips and to modify the magnetic properties 
so that a coincident electrical pulse can write data on the strips. Magnetic 
acoustic systems have some potential in the area of intermediate storage, 
but the packing density is appreciably less than that which can be achieved with 
magnetic bubble memories. 


B2. 2. 8 Semiconductor 

Semiconductor memory system will constitute a large portion of 
any data processing equipment, but only complementary MOS and the nonvolatile, 
variable-thresold MNOS one seem to have mass storage potential. Major 
problems are yield at the higher chip densities and substrate interconnection 
techniques. A wide capacity, speed and power capability is covered by this 
field, and it is believed that it will become the major technology by the end of 
the decade. 
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B2.2. 9 CCD 


The charge-coupled device has a potential packing density that 
rivals the bubble memory. This device will use and appreciate the technology 
that exists within the semiconductor industry. The main application of CCDs 
is in memories ranging from 10 6 to 10 10 bits. The structure of a CCD storage 
element may be even smaller than that of an MOS transistor because no p- or 
n-type diffusion is necessary and no multiple etching of oxide is needed. How- 
ever, the general feeling is that they will find their major applications in 
imaging or in a system which needs the incorporation of CCDs to achieve the 
optimized system performance. Presently, there are several manufacturers 
investigating memory applications for CCDs , including Rockwell Micro- 
electronics, Texas Instruments, RCA, and Intel. 


B2. 2. 10 Beam Memory Technology 

Beam memory is highly regarded as a potential candidate for the 
very large capacity systems of over a billion bits. The principal features 
are low inertia, high resolution, and a departure from the discretely fabrica- 
ted and interconnected storage medium. This type of memory has severe 
problems in the area of erasable storage and optical information conversion. 
Although this technology is still very much in the laboratory stage, many 
manufacturers claim that the system of 10 10 bits should be in production during 
the period of 1974 to 1978. Recent developments in beam memory indicate that 
such conceived data systems are beginning to emerge; examples are the Micro- 
bit system and the Precision Instruments Unicon Mass -Memory System. 


B2. 3 COMPARISON OF MEMORY TECHNOLOGIES 

The comparison of memory technologies was based on the data storage 
alternatives of the RAM Phase B Study done under NASA contract NAS8-27539 
and on the newer technologies disclosed in magazines and professional journals 
listed in References 1 through 23. The comparative data are given in tabular 
form in Tables B-2 through B-6. 
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TABLE B-2. PERFORMANCE PARAMETERS 


Data Storage 
Technology 

Data Rate 
(bits/sec) 

Storage Structure 

Energy Per Bit 
(joule) 

Area Packing 
Density 

f bits/m 2 ( bits/in. 2 )1 

Average Access 
Time (sec) 

Magnetic Tape 

3. 6 x 10 6 

Serial 

1. 5 x 10~ 7 - lo“ 4 

2. 325 x 10 9 
(l. 5 x 10 e ) 

10 

Ferrite Core 
( 1 8 mil) 

3.0 x 10 6 

RA a 

10~ 9 ~ 5 x lo" 4 

3. 875 X 10 6 
(2. 5 x 10 3 ) 

io" 6 

Plated Wire 
( 5 mil) 

5 x 10 6 

RA 

io" 4 

7.75 x 10 6 
( 5 x 10 s ) 


Planar 
Thin Film 

7 x 10 6 

RA 

10“ 5 

3. 10 x 10 s 
( 2 x 10 B ) 


Magnetic 

Bubble 

3 x 10 6 

Sequential 

10* 13 ~ 5X 10’ 5 

1. 55 x 10 9 
(10 G ) 

IO’ 5 

DTPL 

10 6 

Sequential 

2 x 10 _5 

6.20 x 10 7 
(4x 10 4 ) 


Magnetic 

Acoustic 

10 7 

RA 

- 

2 x 10~ 6 



Semiconductor 

10 7 

RA 

10~ 9 ~ 10 _6 

1. 55 x 10 8 to 1. 55 x 10 9 
(10 5 - 10 6 ) 

io” 7 

Charge Coupled 

10 7 

Sequential 


6.20 X 10 9 
(4 x 10 8 ) 


Beam 

8 x 10 7 

RA 


1. 55 x IO 11 
(10 8 ) 

5 ~ 10 msec 


<1 


a. RA — random access, 
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TABLE B-3. PHYSICAL CHARACTERISTICS 


Data Storage 
Technology 

Typical Storage 
Capacity 
( bits) 

Weight 
[kg (lb)] 

Data Density 
[bits /kg ( bits/lb) 1 

Volume 
[m 3 (in. 3 )1 

Data Packing Density 
[bits/m 2 (bits/in. 2 )] 

Magnetic Tape 

10 11 

40. 823 
(90) 

2.425 x 10 9 
(l.lx 10 9 ) 

0.0852 

(5200) 

1.159 x 10 12 
(1.9 x 10 7 ) 

Ferrite Core 

io 7 

181.437 

(400) 

5. 5 x 10 4 
(2. 5 x 10 4 ) 

1.639 
(10 000) 

6.10 x 10* 
(10 5 ) 

Plated Wire 

10 7 

40. 823 
(90) 

2. 425 x 10 s 
(l.lx 10 5 ) 

0.04 92 
(3000) 

2. 014 x 10 8 
(3.3 x 10 3 ) 

Planar Thin Film 

CO 

O 

H 

45.359 

(100) 

2. 205 x 10 e 
(10 6 ) 

0.0492 

(3000) 

_ ... .... 

2,014 x IO 9 
(3.3 x 10 4 ) 

Magnetic Bubble 

10 8 

9.072 

(20) 

1.102 x 10 s 
(5 X 10 6 ) 

0. 00492 
(300) 

2. 014 x 10 8 
(3.3 x10 s ) 

DTPL 

10 8 

34.019 

(75) 

3. 307 x 10 e 
(1.5 x10 s ) 

0. 0295 
(1800) 

3. 356 x 10* 
( 5. 5 x 10 4 ) 

Magnetic Acoustic 

10 8 

204.117 
[ 450) 

4. 850 x 10 8 
(2.2X 10 s ) 

0.1147 

(7000) 

8. 543 x 10 9 
(1.4 x 10 4 ) 

Semiconductor 

io 7. 

21.216 

(60) 

3.748 x 10 5 
(1.7 x 10 5 ) 

0,01966 

(1200) 

5.065 x 10 8 
(8.3 x 10 3 ) 

Charge Coupled 

IO 8 

181.437 
' (400) 

5. 51 2 x 10 s 
(2. 5x 10 5 ) 

0.1179 

(7200) 

7.933 x 10 8 
(1.4 x 10 4 ) 

Beam 

10 9 ~ IO 12 
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TABLE B-4. ENVIRONMENTAL SUSCEPTIBILITY a 


Data Storage Technology 

Temp. 

Shock 

Vibration 

Radiation 

Volatile 

Magnetic Tape 

A 

A 

A 

G 

No 

Ferrite Core 

A 

G 

G 

G 

No 

Plated Wire 

A 

G 

G 

G 

No 

Planar Thin Film 

G 

G 

G 

G 

No 

Magnetic Bubble 

P 

G 

G 

G 

No 

DTPL 

A 

G 

G 

G 

No 

Magnetic Acoustic 

A 

A 

A 

G 

No 

Semiconductor 

A 

G 

G 

MOS - A 
MNOS - A 
Amorphous — G 

MOS — Yes 
MNOS - No 
Amorphous — No 

Charge Coupled 

A 

G 

G 

P 

Yes 


a. G = Good, A = Acceptable, P = Poor. 
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TABLE B-5. TECHNOLOGY EVALUATION AND COST PER BIT 


Data Storage Technology 

Process Simplicity 

Reliability 

(MTBF) 3 
(hr) 

T * b 

Logic 

Cost 

(cents /bit) 

Magnetic Tape 

A 

2 x 10 3 

No 

0. 0002 

Ferrite Core 

G 

2 x 10 4 

No 

1.0 

Plated Wire 

A 

2 x 10 4 


1.0 

Planar Thin Wire 

P or A 

5 x 10 4 


0.5 

Magnetic Bubble 

A 

5800 

Yes 

io" 4 - 0.01 

DTPL 

G 



0.05 

Magnetic Acoustic 





Semiconductor 

A 

10 4 

No 

0.25 - 1.0 

Charge Coupled 

G 



0,05 

Beam Memory 


2 x 10 4 


0.005 - 0.01 


a. MTBF = mean-time-between-failure. 

b. Capability of combining logic and memory operations in the same device. 







TABLE B-6. SUMMARY OF DATA STORAGE TECHNOLOGIES 


Data Storage Technologies 

Advantages 

Disadvantages 

Status 

Tape Recorder 

Digital or analog input. High 
packing density. Light weight, 
small size. Low power require- 
ment. Low cost per bit. Highly 
developed technology. High 
reliability. 

Performance deterioration 
by bearing, tape and head 
wear. Tape is susceptible 
to extreme temperatures and 
magnetic field. Life time is 
limited by moving parts. Non- 
random access device. 

4.497 hits/m (25 000 
bits/ln. ) 

100-track, 0. 0508- in (2-in.) 
tape (expected by 1976) . 

Ferrite Core 

Good resistance to shock, vibra- 
tion, radiation. Highly developed 
technology. High reliability. 
Random access device. 

Low bit density. Excessive 
weight, volume. High power 
consumption. High cost. 

No major improvement in 
bit density and cost per bit. 

Plated Wire 

Nondestructive readout. Good 
reliability. High data rate. 
Random access device. Good 
resistance to shock, vibration, 
radiation. 

Lower bit density. Weight, 
volume precludes mass 
storage use. 

Used in Minuteman Poseidon. 
Univac computers [ 10 7 bits, 
0.715 m 3 (4.3 X 10 4 in. 3 ), 100 
watts] . A significant improve- 
ment was announced by G. E. 
group. 

Planar Thin Film 

Nondestructive readout. High 
data rate. Good resistance to 
shock, vibration, radiation. 
Lower power. Random access 
device. 

Weak output signal. Complex 
production process. 

Used in Burroughs and Univac 
computers. Univac 1832 
[5. Ox 10 6 bits, 0.018 m 5 
(1100 in. 3 ), 22.23 kg (49 lb), 
190 watts ] . 

Magnetic Bubble 

High packing density. Light 
weight. Low power consumption. 
Good resistance to shock, vibra- 
tion and radiation. Logic and 
memory features. 

Sensitive to temperature change. 
Requires bias field to preserve 
data. Requires materials/tech- 
nology breakthrough. Not magnet- 
ically clean. Weak output signal. 

Practical memory available 1 

within 3 years. 

ITT PL 

Permanent bias field not re- 
quired. Low power consumption. 
Good resistance to shock, vibra- 
tion, and radiation. High 
reliability. 

Medium bit density. Weak out- 
put signal. Low data rate. 

Cambridge memories, DOT ram 
4 and 16 ( 1. 55 x 10 7 blts/m 7 
(10 4 bits/in. *) , 0.48 x 0. 27 X 
0.56 m (19 x 10.5 x 22 in.), 

90 watts] . 

Magnetoacous tic 

High data rate. Nondestructive 
readout. Lower power consump- , 
tion. 

Medium bit density. Requires 
temperature compensation. 
Large volume. Relatively 
short lifetime. 

Sylvania "Soniscan. " 
General dynamics "Fame.” 

Semiconductor Random 
Access 

High data rate. Medium power 
requirements. Random access 
device. 

Standby power must be main- 
tained. Production yields on 
large chips low. Large volume. 

Univac 9460 (Moacore, 
5 x 10 s bits) now avail- 
able. 

Charge-Coupled 

Device 

High data rate, Low power. 
High packing density. Pro- 
duction process simple. 

Data must be constantly docked. 
Susceptible to radiation. 

Volatile. 

.. ... 


Beam Add Storage 

Lnput/output completely Isolated. 
High packing density. High data 
rate. 

High power consumption. Poor 
efficiency. Poor reliability. 
Nonerasable. Read-only type 
memory. 

Micro- Bit computers. 
ILL1AC IV computer. 
10 10 bits, 0.01 ~ 0.005 
cents/bit. 


a. Features have been demonstrated separately only. 
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B2.4 MEMORY AND STORAGE REQUIREMENTS 


B2.4. 1 Mainframe Memory 

The mainframe memory must provide the capability for central proces- 
sor to control the whole system and to perform the other related functions. A 
high speed, random access memory of 3.6 x 10 6 bits is recommended. 

B2.4.2 Auxiliary Memory System 

This system is to provide memory for performing the following functions: 

1. Storing computer software. 

2. Storing utility routines, mathematical routines, etc. 

3. Storing run-time data. 

4. Data acquisition and distribution. 

5. Onboard checkout. 

A medium speed, random access, read and write buffer memory with a 
capacity of 10 7 bits is recommended. 


B2.4.3 High Speed Buffer Storage 

Direct interface with a computer or the possibility of data link to other 
storage devices results in a buffer requirement of a fast, random access device 
with the following specifications: 

1. Capacity 10 6 ~ 10 8 bits. 

2. Data rate 10 8 bits/sec. 


B2.4.4 Intermediate Storage 

This storage provides the short duration for high data rate output that 
cannot be handled by either buffer of mass storages. A system with a capacity 
of from 10 8 to 10 11 bits and a data rate of 10 s bps is recommended. 
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B2.4.5 Mass Storage 


This sytems is a permanent storage medium for data gathered during a 
mission. Under this situation a mass storage system must have the capacity of 
10 11 bits or greater. 

B2. 5 TECHNOLOGY RECOMMENDATION 

The technologies identified for each area of application are based on the 
comparison of the technologies in Section B2. 3. Since the technology status may 
change considerably from time to time, depending on the existing research 
efforts, the projected technologies which may one day become available have 
been taken into consideration. The recommended technologies are summarized 
in Table B-7. 


TABLE B-7. CANDIDATE TECHNOLOGIES 


Category 

Significant 

Characteristics 

Recommended 

Technologies 

Main Memory 

Less than 10 7 bits 

Core, plated wire, semi- 
conductor. 

Auxiliary Memory 

10 7 bits 

Random Access 

DOTram (Cambridge). 
Plated Wire (G.E.). 
Drum, semiconductor. 
Thin film. 

High Speed 
Buffer 

IQ 6 to 10 8 bits 

Plated wire. 

COS/MOS, MNOS, Amorphous. 
NMOS, CCD-MNOS. 

Thin film. 

Intermediate 

Storage 

10 8 to 10 11 bits 

Plated wire. . 
Magnetic bubble. 
CCD-MNOS. 
Tape recorder. 
Beam memory. 

Mass 

Storage 

10 11 bits or greater 

Tape recorder.. 
Beam memory. 
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B2. 6 MEMORY AND STORAGE SELECTION 


This section reports a survey of existing, or proposed, memory and 
storage devices for each category discussed in the previous section. The sur- 
vey included reviews made by memory researchers and published in manufac- 
turers’ brochures, technical magazines, and professional journals. The 
selection of memory and storage systems in a candidate technology were made 
by comparing physical characteristics, performance parameters, environ- 
mental susceptibility, reliability, and cost per bit. 


B2, 6, 1 Ferrite Core Memories 


Because of the power, volumetric efficiency, weight and cost, the core 
memories are best suited for use in the mainframe memory. Of the six off- 
the-shelf memories compared, the Ampex, Data Products, and CDC Alpha-1 
memories are more favorable than the others. Comparison of the memories 
surveyed are summarized in Table B-8; detailed descriptions of each memory 
are given in Section B2. 7, 


B2, 6. 2 Plated-Wire Memories 

The complex manufacturing process of plated- wire memories and the use 
of high packing density in relatively inexpensive semiconductor memory are the 
major factors that have made the plated-wire memories incompetent in the 
commercial field, although plated wire is able to withstand severe vibration 
and shock and is capable of retaining its high reliability in hostile environments. 
Because of these conditions, most plated-wire memories are manufactured for 
special purposes, military or aerospace applications. Of the few memories of 
this type that have been produced, those made by Control Data, G. E. , and 
Honeywell are intended for aerospace applications. The general features of 
these three systems, selected for main frame, auxiliary, and high speed 
categories, are given in Table B-9 and detailed descriptions are given in 
Section B2, 8, 


B2. 6, 3 Semiconductor Memories 


The possibility of creating highly sophisticated memory systems with 
very low cost per bit and high packaging density give a strong incentive for 
explosive growth in the semiconductor memory industry. The very keen 
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TABLE B-8. OFF-THE-SHELF CORE MEMORY COMPARISON 


Company 

Ampex 1800 

Cambridge Expanda 
Core 18 

Data Products 
Store/333 and 336 

CDC 

Alpha-1 

Lockheed 

Fabri-Tex 

Crusader 

Core Type 

3-D, 3- wire coincident- 
current 

3-D, 3-wire coincident- 
current 

3-D, 3-wire coincident- 
current 

2§D, coincident 
current 

3-D, 3-wire coincident- 
current 

3-D, 3- or 4-wire 
coincident-current 

Core Diameter [m (mil)J 

4.5?2x 10" 4 (18) 

5. 588 x 10~ 4 (22) 

4.572 X 10~ 4 (18) 

5.334 x 10 -4 
(21) 

4, 572 x 10~ 4 (18) 


Access Time ( nsec) 

250. 340 

350 


500 

750, 1500 


Cycle Time 


1.0 nsec (4KX 18 bits) 

650, 750 nsec 

1 msec 



Standard Capacity 

2Kx9, ® x 18 bits 

4K, 16K words 

8K x 18 bits 

1 6K x 32 bits 

4K x 18, 8K x 18 bits 

2,4, 8, and 16K 

Maximum Capacity (bits) 

16K X 36 


65K x 18 

128K x 32 

131K x 18 
520K x 18 
524K x 24 
65K x 192 


Bits/Word 

9,12,16,18,24,36 

12,16,18 

18 

32 

18, 24 

1 up to 80 

Expandability (words) 

8K 

4K 

Si 

16K 

SK 

2K 

Voltage Required (Vdc) 


5, -18 

5, -15, +15 

-15, -5.7, 15 

+5, +15, -5 


Power Consumption (watts) 

45.0 (ZK x 9 bits) 

74.0 ( 8K x 18 bits) 

174.7 (16K x 16 bits) 
145.5 (8K X 16 bits) 

70.0 { SK x 18 bits) 

50 watts (stand- 
by) 250 (max) 
165 (av) 

107.0 (standby) 
(65K x 18 bits) 

213.0 (worst) 
(65K x 18 bits) 


Operating Temperature (° C) 

0 to 65 


0 to 55 

MEL- E- 5400 
Class 2 

0 to 50 

-55 to 95 

Relative Humidity 

95%, no cond. 

95%, no cond. 

90%, no cond. 

MIL- E- 5400 
Class 2 

90%, no cond. 

90%, no cond. 

Cooling Air Flow Rate 
[ m 3 /min ( ft 3 /min) ) 

2. 832 (100) 

1.416 (50) 

1.699 (60) 

MIL-E-5400 
Class 2 

8.495 (300) 


Weight (kg (lb)] 

2.04 (4. 5) 

( 8K x 8 bits) 

2.267 (5.0) 

( BK x 16 bits) 

1.47 (3.25) 
(S<x 18 bits) 

2.041 (4.5) 

( 16K x 32 bits) 

0.907 (2.0) (1SK x 8 
bits, memory card OQly) 


Size l m 3 (in. 3 )] 

0.2032 x 0.0254 x 0.059 
(8. 0 x 1. 0 x 2.125) 

0.2921 x 0.0457 x 0.348 
(11. 5x 1.8 x 13. 7) 

(8K x 16 bits) 

0. 0635 x 0. 2032 x 0. 2794 
( 2. 5 x 8 x 11) 

( 8K x 1 8 bits) 

0.257 x 0.194 
x 0. 395 

(10.125 x 7.625 
x 15. 562) 

0.292 x 0.343 x 0. 0203 
(11. 5x 13. 5x 0.8) 
(8K x 18 bits) 

0. 102 X 0. 102 X 0. 0250 
(4.0 x 4.0 x 0.985) 

(8K X 16 bits) 

Vibration 




MIL-E-54 00 
Class 2 


5 to 2000 Hz 

Shocks 




MIL-E-54 00 
Class 2 


50 g for 1 1 msec 










































































































TABLE B-9. GENERAL CHARACTERISTICS OF 
PLATED-WIRE MEMORIES 


parameter 


Wire Type 


Wire Diameter, 
m (mil) 


-Access Time, 


Full Cycle Time, 


Standard Capacity 


Maximum Capacity 


Bits/Word 


Expandability, 
( words) 


Voltage Require- 
ment, Vdc 


Power Consumption 
(watts) 


Size, m 3 (in. 3 ) 


Weight, kg (lb) 


Operating Tempera 
ture, ''C 


Relative Humidity 


CDC 496 


Beryllium-Copper 


1* 27 x 10 4 
(5.0) 



Tungsten 


6.35 x 10 6 
(2. 5) 


Honeywell 


Beryllium-Copper 


1. 27 x 10~ 4 
(5.0) 



8K x 16 bits 


24K words 


8K x 25 bits 


® x 16 bits 


3ZK words 



0. 112 x 0. 109 X 0.083 0. 244 x 0.169 x 0.0445 

(4. 4 x 4.3 x 3.3) (9.6x6.5x1.75) 

(at words) ( at words) 


1.134 (2.5) 


1.814 (4.0) 


12 (standby) 
19 (read) 

21 (write) 


0. 194 X 0.121 x 0. 330 
(7.62 x 4.75 x 13) 

( 8K words) 


6. 804. (15) 


-55 to +71 
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competition is causing a decrease in the costs of semiconductor memories. The 
realization of memory capacity of 32K bits and storage capacity of 512K bits 
would be feasible before 1980, with the possible low cost per bit ranging from 
0.02 to 0.05 cent. General features of selected semiconductor memories are 
listed in the Table B-10. 

Among the surveyed off-the-shelf memory systems, the NMOS LSI RAM 
memory would be the best choice based on speed] however, it has the disadvan- 
tage of higher cost per bit then its PMOS counterpart. The nonvolatile, 
radiation-hardened, amorphous memory and the Litton militarized MOS memory 
should probably be considered for the medium speed memory and aerospace 
applications. 

Another area being actively pursued for the high performance memories 
are MNOS and silicon-on-sapphire (SOS) devices. At least three companies 
are actively engaged in the development of MNOS memories. Uni vac Defense 
Systems has developed block-oriented, random access, 2-K MNOS memory 
which is scheduled for production in late 1974 and is intended for computer 
applications. While Univac is developing a 1.15-megabit module, the develop- 
ment of a much larger 1. 8- million- bit MNOS memory module has been under- 
taken by Westinghouse. This module will contain 1024 blocks of data with each 
block having 2048 characters each of which is 9 bits long. Access time for the 
memory will be 10 msec. A different approach, one that intends to combine 
both die advantages of CCD and those of MNOS, has been undertaken by Rockwell 
to develop a high performance, highly sophisticated CCD- MNOS memory. SOS 
RAM memory is also being pursued by Rockwell and will combine the high speed 
of bipolar with the low manufacturing costs of MOS. The SOS RAM will be 
cheaper than its bipolar equivalent; for 1-K device it will consume 250 mW of 
power. The memory cycle time is 100 nsec and is TTL compatible. 


B2. 6. 4 Drum and Disc 


Due to the cost, flexibility, and manufacturing complexity, many manu- 
facturers of computer peripherals are converting from drum to disc systems. 
Efficient and flexible disc systems have made it difficult for drum systems to 
maintain a leading role in applications that require random access, high data 
rate devices. Disc systems are replacing drums in most commercial storages. 
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TABLE B-10. SEMICONDUCTOR MEMORIES 


Parameter 

Advanced Me 

mory Systems 

Energy Conversion 
Devices 

Intel 

Litton 

Memory Type 

P-MOS LSI 
RAM memory 

N-MOS LSI 

HRM-2048, nonvolatile, 
amorphous Semiconductor 

Dynamic RAM 
MOS Chip 

Military MOS 
Memory 

Standard Capacity 

2K x 4K bits 

ZK x 4K bits 

2048 bits 

32K x 18 bits 

4K x 33 bits 

Maximum Capacity 

256K x 18 bits 

102K x 18 bits 


65K x 144 bits 

16K x 33 bits 

Expanability, words 

4K 

4K 


4K 

4K 

Bits /Word 

16, 18 

16, 18 

8, 16, 32 

16, 18 

33 

Interface 

TTL 


ttl/dtl 

TTL 

TTL 

Access Time, nsec 

300 (4K x 18 bits) 

110 (12K x 17 bits) 


.325 (32K x 18 bits) 

550 (4K x 33 bits) 


350 (4K x 18 bits) 

~ 200 (12K x 17 bits) 


450 

650 

Voltage Require- 
ment, Vdc 

20, 23, 5 

15. 5, 5. 0, -5. 2 

5, 26 

3.5, 19.7, 5 


Power Consumption, 
watts 

400 (operating) 
300 (standby) 
(including ECL a 
12K x 72 bits) 

40.0 (4K x 18 bits) 


35 (4K x 18 bits) 

(12 per additional 4K) 

185.0 (operating) 
(16K x 32 bits) 

73.0 (standby) 

Size, m 3 (in. 3 ) 

0. 1 91 x 0. 305 x 5.72 
(7. 5x 12.3 x 225) 
(4K x 18 bits) 

0.221 x 0.305 x 
0.483 ( 8. 7 X 12. Ox 
19. 0)( 12K x 72 bits) 


0. 208 x 0.267 x 0.127 
( 8. 175 X 10. 5 x 5.0) 
(32K x 18 bits) 

0.191 x 0.193 x 4.95 
( 7. 5 X 7. 6 x 19. 5) 
(16K x 33 bits) 

Weight, kg (lb) 

0.113 (0.25) 
(4K x 18 bits) 

13.608 (30) 



13.608 (30.0) 
( airborne) 

Operating Temper- 
ature, ”C ' 

0 to 55 

0 to 55 

0 to 70 

0 to 50 


Relative Humidity 




90%, no cond. 

MIL- E- 54 00 

Radiation 



Hardened 



Cooling Air Flow 


9. 91 m 3 /min 
(350 CFM) 




Cost/Bit, cent 

1.5 

3.0 

1.0 




a. 


ECL — external control. logic. 




Based on a review of several off-the-shelf drum systems, the IBM 
system/4 pi mass memory seems to be the best one for use as an onboard 
auxiliary memory system. This memory is expressly intended for airborne 
applications and has the general features shown in Table B-ll. Poor shock 
and vibration resistances are the factors that have disqualified disc systems 
for ae or space applications because those features are critical during launch. 


B2. 6. 5 Thin- Film Memories 


This technology is not widely supported by the memory manufacturers. 

Of the few thin- film memories that have been produced, all are intended for 
special applications. Based on a review of thin- film memories, the Univac 
Mated- Film memory, used in 1832 Avionics Computer, seems to be most favor- 
able. The 8K-word stacks of Mated- Film memory elements are combined into 
a 16K-word bank for the processor and input- output controller from which a 
32K-word memory module is constructed. The operational cycle time is 750 
nsec. The module weighs 19.958 kg (44 lb) and is 0.303 x 0.340 x 0.218 m 
(11.9 x 13.4 x 8. 6 in.) in size. 


B2. 6. 6 CCD 

The CCD memory system is still in the development stage and is being 
investigated by most semiconductor manufacturers, including Rockwell Micro- 
electronics, Texas Instruments, RCA, and Intel. 


B2. 6. 7 Magnetic Bubble Memories 

No commercial bubble memory is available at the present time, although 
technology offers a great potential for memory application. Presently Bell 
Laboratories, Rockwell Micro-electronics, RCA, and Monsanto are actively 
pursuing the bubble memories. 


B2. 6. 8 DPTL 


The DOTram memories, products of Cambridge Memories, was selected 
for this technology category. A typical system is a block-oriented random 
access, solid state, nonmechanical, and nonrotating device. Data packaging 
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TABLE B-ll. characteristics of A REPRESENTATIVE IBM 
SYSTEM/4 Pi MASS MEMORY 


Parameter 

Capability 

Capacity 

15 megabits 

Recording Density 

1960 bits/in. ; 39 960 bits/track 

Number of Tracks 

392 data tracks; 2 timing tracks (plus 
spares) 

Access Time 

6. 25 msec (average) 

Data Transfer Rate 

3. 2 Mbs per track 

Number of Nine- Track Heads 

50 

Size and Weight 
Rotor 

0. 1651 m ( 6. 5 in. ) diameter, 0. 2743 
m ( 10. 8 in. ) long 

Drum Subassembly ( Drum 
Unit plus all Read/Write 
Electronics) 

0. 222 x 0. 305 x 0.483 m 
( 8. 75 x 12 x 19 in.) = 0.033 m 3 
(1995 in. 3 ); 20.412 kg (45 lb) 

Power Subassembly 

0. 222 x 0. 305 x 0. 203 
( 8. 75 x 12 x 8 in.) = 0.014 m 3 
( 840 in. 3 ); 11.34 kg (25 lb) 

Power Required 

390 watts 

Drum Speed 

4800 revolutions/min 
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densities up to 10k bits/in. 2 can be attained, without the use of record gaps to 
separate records. Capacity ranges from 65K to 16M bits but can be expanded 
to 128M bits in later models. Word length is 8 to 36 bits, and access is random 
by block, serial by word. This system provides 1 psec maximum block access 
time, 1. 75 msec average word access time, and TTL interface. A 4M-bit 
system fits 0.4826 m (19 in. ) rack and is 0. 267 m (10. 5 in. ) high by 0. 559 m 
(22 in.) deep. Power consumption is 90 watts for 8-bit parallel; standby power 
is 10 watts. 


B2. 6. 9 Magnetic Tape and Beam Memory 

Three currently available systems capable of storing more than a tril- 
lion (10 12 ) bits are: 

1. Ampex Terabit Memory (TBM) System. 

2. Grumman Masstape System. 

3. Precision Instruments Unicon. 

Maximum capacities range from 88 gigabytes in the Precision Instrument 
Unicon, through 110 gigabytes in Grumman’ s Masstape, to 362 gigabytes for 
the Ampex TBM. Two of the three systems, TBM and Masstape, will have 
incremental capabilities. Besides Precision Instrument’s beam- addressable 
system, Micro- Bit has developed a system which is composed of several 
electron-beam addressable memory tubes, each capable of storing one million 
bits of data. Each tube is about 0. 0381 m (1. 5 in. ) in diameter and uses 
proprietary materials for storage. 


B2. 7 SURVEY OF THE OFF-THE-SHELF CORE MEMORIES 

The ferrite core type devices are predominantly manufactured for main 
frame computer memory systems. The core costs are decreasing primarily 
because of the significant utilization of the process of punching core out of a 
tape of ferrite material and the availability of newer materials which allow 
wider operating temperature ranges of -25 to 100° C without temperature com- 
pensation. In spite of its basic cost, speed/volume limitations, and high power 
requirements, the ferrite core still maintains a dominant position in relation 
to other technologies in space applications because it is a highly developed and 
reliable system. 
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B2.7.1 Ampex 1800 and 3000 Series Core Memories 

The 1800 series planar core memories offer the two optional access 
times of 250 and 340 nsec for the standard capacity ranging from 2K x 9 to 
8K x 18 bits. Word lengths of 9, 12,16, and 18 bits are available for particular 
system requirements. These memories are currently available and are_ man- 
ufactured by implementing 3-D, coincident-current, 3-wire, 4. 572 x 10 4 m 
(18- mil) , medium core arrays, and packaged on three removable printed cir- 
cuit boards in modular fashion. Permissible module expansion scheme in 8K 
increments results in low-cost expandability. Only two different operating 
voltages are needed, mainly +5 volts and -15 volts. The power consumption 
is 45 watts for 9 bits and 74 watts for 18 bits. No temperature compensation 
is required in power supplies. An Ampex silastic bonding technique is used to 
fabricate the core modules, with a thermal path for dissipating the core switch- 
ing heat and minimizing the temperature gradients. Continuous operation in an 
environment of 0°C to 65° C ambient temperature without condensation at 95 
percent relative humidity requires 2. 832 m 3 /min (100 ft 3 /min) of cooling air. 

It is also claimed by the manufacture that these memories have identical inter- 
faces and can be operated on the same I/O bus, a particularly useful feature 
for asynchronous processors. Ampex* s 3600 series offers a capacity of 8K 
and 16K words of 24 and 36 bits with the same performance and flexibility as 
the 1800 series. A typical module of 8K x 18 bits weighs about 2.04 kg (4. 5 lb) 
and had dimensions of 0.2032 x 0.254 x 0.0535 m ( 8.0 x 10. 0 x 2.105 in.). 


B2. 7.2 Cambridge Memories Expanda Core 18 Memory System 

This currently available system has a 3-D, 3-wire, coincident-current, 
5. 588 x 10~ 4 m (22 mil) , lithium ferrite, magnetic array. The Expanda Core 
18 series has the capability of expanding from 4K to 10K systems by adding 
plug-in, 4K-storage boards each of which contains a core stack and associated 
device and sense circuitry. These products offer three optional word lengths 
of 12, 16, and 18 bits. For a given typical memory size of 4K x 18 bits, it 
provides speed characteristics of 1.0 jusec for full cycle, 1.1 psec for split 
cycle, and 350 nsec for access time. It occupies 3. 11 x 10 3 m 3 (190 in. 3 ) and 
the weight of the package is dependent on the number of control cards and the 
number of standard memory modules used. Two dc voltages of +5 volts and 
-18 volts are required to drive such systems. Table B-12 lists the dc current 
values and power consumption based on system configuration. 
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TABLE B-12. CURRENT AND POWER CONSUMPTION VALUES FOR THE 
EXPANDA CORE 18 MEMORY SYSTEM 



Configuration 

12- Bit 

16- Bit 

18-Bit 

Voltage 

4K 

8K 

16K 

4K 

SC 

ISC 

4K 

SC 

16K 

4 5 

1.5 

1.9 

2.7 

1.7 

2.1 

2.9 

2.0 

2.5 

3.5 

-18 

5.8 

6.5 

7.9 

6.8 

7.5 

8.9 

7.2 

7.9 

9.3 

Power (watts) 

111. 9 

126.5 

155. 7 

131.0 

145.5 

176. 7 

139.6 

154.7 

184.9 


Cambridge Memories claims that its Expanda Core 18 series can oper- 
ate in a temperature range of 0 to 50° C, with a continuous supply of ambient 
cooling air and with 0 to 95 percent relative humidity; it is virtually immune to 
attitude influence and can withstand the shock and vibration that is encountered 
during commercial shipping. 


B2. 7.3 Data Products Store/333 and 336 Core Memories 


The Data Products Store/333 and 336 memories are currently available 
and offer memory full cycle speed of 650 and 750 nsec and are 3-D, 3- wire, 
coincident-current, 4. 572 x 10 4 m (18 mil) , ferrite arrays. The manufac- 
turer claims that the high yield of consistent cores results from the use of 
unique property "roll/cut" tape process. These memories have basic 8K word 
by 18 bit core memories and are capable of extending their capacity in a standard 
0. 22 m ( 8. 75 in.) chassis to 65K x 18 in 8K increments. The medium memory 
size of 32K x 18 bits can also be obtained in a 0. 133 m (5.25 in. ) chassis. The 
modular flexibility can be achieved by using two basic module configurations, 
Types I and II models. The basic memory modules, store/333 and 336, Type I, 
contain all circuitry necessary for memory operation and can be installed 
directly in the main frame. In a multimodule configuration, store/333 and 336, 
Type II, two Memory Interface Assemblies are utilized. In these two memory 
modules, the size of the printed circuit boards used is approximately 
0. 203 x 0. 279 m ( 8 x 11 in.) . Each basic storage module weighs 1,474 kg 
(3.25 lb). The power required to drive these systems is three dc voltages: 

+5, -15, and +15 volts. Table B-13 lists individual core power requirements 
and consumption per basic storage module ( BSM) . 
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TABLE B-13. VOLTAGE, CURRENT, AND POWER REQUIREMENTS 
FOR DATA PRODUCTS STORE/333 AND 336 CORE MEMORIES 



Standby 

Average 

Worst Case 
(All Zeroes) 

Each Additional 
Depopulated Type II 
BSM Installed 

Voltage, dc 





+ 5 ±3% 

3. 0 amps 

3. 5 amps 

4. 1 amps 

1.41 

-15 ±2% 

0.65 

2.8 

4.6 

0.35 

+15 ±3% 

0.10 

0.5 

0.7 

0.1 

Power (watts) 

21.75 

67.0 

100.0 

13. 80 


These memories are capable of performing random access mode and 
can operate in the 0 to +55° C incoming, continuous cooling air flow at 
1. 699 m 3 /min (60 ft 3 /min) minimum and 90 percent of maximum relative 
humidity without condensation. Each system is designed to withstand shock 
and vibration encountered in normal commercial computer environment. 


B2. 7.4 Fabri-Tek Crusader Series 


These currently available memories have 3-D, 3- or 4-wire, coinci- 
dent-current, ferrite arrays. Crusader offers various memory sizes, 2K, 

4K, 8K, and 16K, with a wide range of word lengths varying from 1 to 80 
bits. A desired memory can, therefore, be assembled by using standard 
stacked frames that are double-sided, each measuring 1.02 x 1.02 m 
(40 x 40 in.), providing 4.19 x 10 3 m (0. 165 in. ) frame- to- frame spacing. 
The physical dimensions of a typical memory organization are listed in the 
Table B-14. These memories are operable in the 200 nsec rising and falling 
time, 250 nsec pulse duration time, and 430 nsec maximum with 5 mV of 
signal output. Under the full drive condition these memory systems require 
1. 0 mA per degree centigrade current compensation. Fabri-Tek claims some 
of these products can meet the following environmental specifications: 
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Operating Temperature 


-55 to 95° C 


Vibration 5 to 2000 Hz 

Shock 50 g for 11 msec 

Relative Humidity 90%, no condensation 


TABLE B-14. CRUSADER'S STANDARD MEMORY DIMENSIONS 


Word/Bit Size 

Dimension, m 3 (in. 3 ) 

2K x 16 

4K x 16 

8K x 8 

16K X 4 

0. 102 x 0. 102 x 0.017 
(4.0 x 4.0 x 0. 655) 

2K x 32 

4K x 32 

8K x 16 

16K x 8 

0. 102 x 0. 102 x 0.025 
(4.0 x 4.0 x 0.985) 

2K x 48 

4K x 48 

SK x 24 

16K x 12 

0.102 x 0.102 x 0.033 
(4.0 x 4.0 x 1.315) 

2K x 64 

4K x 64 

8K x 32 

16K x 16 

0. 102 x 0. 102 x 0. 042 
(4.0 x 4.0 x 1. 645) 


B2. 7. 5 Lockheed Electronics Core Memory 

The Lockheed Electronics memory system is a coincident-current, 3-D, 
3- wire, 4* 572 x 10 4 m (18 mil), lithium ferrite array. This line of system 
products comprises 4K x 18, SK x 18 basic building blocks, and 65K x 18 and 
65K x 24 submodule. By using additional magnetic boards, the system capacity 
may be expanded in 8K increments to a maximum of 131K words or 18 boards. 

A fully expanded system capacity of 65K x 192, 524K x 18, or 524K x 24 bits 
is available from the contribution of eight submodules. Memory cycle speed 
varies from 750 nsec to 1500 nsec, depending on the memory size and the 
system configuration. Power requirements and consumption are listed in 
Table B-15. These memories are able to withstand vibrations and shocks that 
are encountered in handling and servicing commercial type electronic hard- 
ware and are capable of being operated in a temperature range of 0 to 50° C, 

90 percent relative humidity with no condensation in a continuously cooling air 
flow of 8.495 m 3 /m in (300 ftVmin). The physical characteristics are: 
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Board Size 


0. 292 x 0. 343 m ( 11, 5 x 13. 5 in.) (nominal) 


Mounting Centers 0.0203 m (0. 8 in.) (minimum) 

Weight Approximately 0. 907 kg (2 lb) per card 


TABLE B-15. POWER REQUIREMENTS AND CONSUMPTION 
FOR LOCKHEED ELECTRONICS CORE MEMORY 



Configuration 



18- Bit 



36- 

Bit 



SC 

G5K 

8K 

32K 


Standby 
(A) ' 

Worst Case 
(A) 

Standby 

(A) 

Worst Case 
(A) 

Standby 

(A) 

Worst Case 
(A) 

Standby 

(A) 

Worst Case 
(A) 

Voltage, Vdc 

5 

2. 5 

2.5 

10.5 

10.5 

5.0 

5.0 

B 

10.5 

15 

0. 5 

6.25 

3.3 

9.7 

1.0 

12.5 


15.0 

-5 

0.12 

0.12 

1.0 

1.0 

0.25 

0. 25 

1.0 

1.0 

Power (watts) 

20. 6 

106. 85 

107.0 

213.0 

91.28 

213.75 

107.0 

282. 5 


B2. 8 PLATED- WIRE MEMORIES 

This technology has suffered a major setback because of difficulty in 
obtaining a well defined, localized magnetic activity. It is unlikely that plated- 
wire memories will become commercial mainframe memories; however, they 
are still candidates for military and aerospace applications because of their low 
power, nondestructive readout, and relative insensitivity to the effects of 
radiation. They can readily be constructed to be resistant to shock, accelera- 
tion, and vibration. Few companies have produced plated-wire memories and, 
since this technology has lacked strong incentive, it has remained relatively 
static. To date, most plated-wire memories have been manufactured for mili- 
tary and aerospace main frame computer systems. 


B2. 8. 1 Control Data Plated-Wire Memory 

Control Data Memory Systems intended for aerospace application com- 
puters are plated-wire memories incorporating C-MOS or TTL interface. 

Since the manufacturer claims these products satisfy the requirements of high 
reliability in an aerospace environment, it is of interest to examine their 
general characteristics in Table B-16. Features that help to qualify this 
line of products for use in aerospace applications are compared for three com- 
puters in Table B-17. 
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TABLE B-16. CDC PLATED-WERE MEMORY 



Configuration 

Characteristic 

8K-Word by 16- Bit 

IK- Word by 16-Bit a 

■L 

8K-Word by 16- bit 

Interface 

C-MOS 

C-MOS 

TTL 

Size, m 3 (in. 3 ) 

0.102 x 0.102 x 0.051 
(4.0 x 4.0 x 2.0) 

0.094 x 0.079 x 0.022 
(3. 7 x 3.1 x 0. 85) 

0.112 x 0.109 x 0.091 
(4.4 x 4.3 x 3. 6) 

Weight, kg (lb) 

0. 907 (2) 

0.236 (0. 52) 

1.09 (2.4) 

Power, watts 

2. 2, operating 

2. 0, operating 

3. 5, operating 

Capacity 

8K x 16 bits 

IK x 16 bits 

8K x 16 bits 

Access Time, nsec 

900 

900 

900 

Read Cycle Time, msec 

1.6 

1.6 

1.6 

Write Cycle Time, msec 

2.4 

800 

2.4 

Operating Temperature, 
°C 

-20 to 71 

-30 to 71 

-20 to 71 

Operating Humidity 

94% 


94% 

Vibration, g 

3. 5 

10 

15 

Shock 

25 g, 25 msec 

150 g, 30 msec 

30 g, 11 msec 

Acceleration, g 


20 



a. Hybridized elect. 

b. Ultra- rugged construction. 







TABLE B-17. COMPUTER CHARACTERISTICS 


Characteristic 

Computer 469-01A 

Computer 469-02A 

Computer 469-03A/B 

Type of Machine 

General purpose, storec 

program, digital compub 


3r 



Processor Organization 

Word organized, single address 

m « i - i. 

Number of Instructions 

42 

Addressing Modes 

Direct indexed direct, and indirect 

Register File 

16-word, addressable as addresses 00000 through 0OO17 8 

Program States 

Normal, interrupt 1, interrupt 2, and interrupt 3 

1 1 1 

Arithmetic 

Binary arithmetic — fixed point, two's complement, factional, single and 
double precision add, subtract, and two's complement instructions 

... | 1 

Type of Memory 

i 1 

Word organized, random access, NDRO plated wire, divided into scratchpad 
and write-protected areas; write-protectod area can be loaded when computer 
is connected to support equipment . 

Word Length 

16 bits 

Input/Output 

One nonbuffered 16- bit c 
nel select code allows co 
equipment 

tiannel; serial input and output capability; 4-bit eban- 
mputer to interface with 15 pieces of external 

Clock Frequency, MHz 

2.0 

2.5 

2.5 

Operating Temperature, 
°C 

-20 to 60 

0 to 50 

-20 to 70 

baseplate temperature 
when operating in an 
ambient air temperature 
of -55 to 95“ C 

Vibration 

Capable of withstanding in 
insulators: 5 to 20 Hz, 2. 5 
double amplitude; 20 to 500 

iny axis without vibration 
4 x 10 3 m (0.10 in. ) 

Hz + 2 g peak 

As specified by curve 
IV of MIL- E- 5400 

Acoustic Noise 



Maximum of 120 dB 
relative to 0.0002 
dync/cm* at frequencies 
between 20 and 10 O00 Hz 

Shock 

Capable of withstanding 18 
consisting of three shocks 
along each of three mutual 
shock impulse time duratic 
— 

impact shocks of 20 g, 
in opposite directions 
y perpendicular axes; 
n is 111 msec 

As specified by MIL- E- 
54 00 when mounted with- 
out isolation 
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TABLE B-17. (Concluded) 


Characteristic 


Computer 469-Q1A 


Computer 469-02A 


Computer 469-03A/B 


Other Environmental 
Conditions 


Sand, dust, humidity, 
and salt fog as specified 
by MIL- E-5400 


Performance 


As specified by CDC Engineering Specification No. 57776800 latest revision; 
for programming details, see Computer Programming Reference Manual. 


Memory Size, words 


9216 


4096, 8192, 12 288, 
16 284 or 24 576 


8192, 16 3 84, or 24 576 


Scratchpad Area 


2048 words, address- 
es ooo2o 0 through 
03777 8 


Available in increments of 1034 words; total to be 
as specified in each individual purchase order 


Write- Protected 


6144 words, address- 
es 04000 3 through 
17777 B 


Available as the difference between total memory’ 
and scratchpad 


Read-Only Memory 


1024 words of non- 
alterable ROM address- 
es 20000 a through 
2177 8 


None 


None 


Dimensions, m (in.) 


0.107 x 0.129 x 0.122 
(4.2 x 5.1 X 4.8) 


0.107 x 0.129 x 0.064 
(4.2 x 5. 1 x 2.5), 4K 
0.107 x 0. 129 x 0.076 
(4.2x5. lx 3.0), 8K 
0.107 x 0. 129X 0.114 
(4.2 x 5.1 x 4.5), 12K 
0.107 x 0. 129 x 0.127 
(4. 2 x 5.1 x 5.0), 16K 
0. 107 x 0.129 x 0.178 
(4. 2 x 5.1 x 7.0) , 24K 


0. 119 x 0.127 x 0.076 
(4. 7 x 5. Ox 3.0), 8K 
0. 119 x 0. 127 X 0.119 
(4. 7 x 5.0 x 4. 7), 10K 
0. 119 x 0. 127 x 0.170 
(4.7 x 5.0 x 6. 7), 24K 


Weight, kg (lb) 


3. 25 


Less than: 

1.59 (3.5), 4K 
1.81 (4.0), 6K 
2.27 (5.0), 12K 
5.5 (5.5), 1GK 
3.17 (7.0), 24K 


Less than: 

2.27 (5.0), HK 
3.17 (7.0), 16K 
4.08 ( 9.0), 24K 


Power Required 


15 Vdc, -5 Vdc, 
3 Vdc, -15 Vdc 
18 watts max 


-15 Vdc, -5 Vdc, 
3 Vdc, +15 Vdc 
4K, 13 watts av 
8K, 14 watts av 
12K, 15 watts av 
16K, 16 watts av 
24K, 18 watts av 


-15 Vdc, -5 Vdc, +5 Vdc, 
+15 Vdc; 8K, 14 watts av 
1 OK , 16 watts av 
24K , 1 8 watts av 
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From examination of Tables B-16 and B-17, it is obvious that this line 
of memory products are specifically manufactured to meet an aerospace appli- 
cation environment in which they are capable of withstanding rugged vibration, 
shock, and acceleration situations. Another feature that makes them attractive 
for use in aerospace systems are their low power, small size, and light weight. 
However, the relatively poor volumetric efficiency and inferior price/perfor- 
mance tend to make this technology uneconomical for memory size greater than 
10 s bits. 


B2. 8. 2 General Electric Tungsten Wire Memories 

A new memory array recently developed by G. E. Aerospace Electronics 
System Department ( AESD) is four times smaller and lighter than conventional 
plated- wire memories, packs four times more information, and requires only 
one-half the power consumption of other available systems. This dramatic 
revolution in size and power consumption is achieved through use of magnetic 
plating on a tungsten wire only half the diameter of conventional beryllium- copper 
strands and through application of wire- electroplating process developed at 
G. E, Research and Development Center. Diameter of the tungsten wire in the 
new G. E. memory is 6. 35 x 10~ 5 m ( 2. 5 mil) , only half that of 1. 27 x 10" 4 m 
( 5 mil) copper wire presently used. Although plated wire using beryllium 
copper is available in the smaller size, G. E. engineers say tungsten substrate 
results in greater production yields, better than 90 percent, and lower manufac- 
turing costs. Average yield for the industry is about 60 percent. 

Size of the memory presently being built by G. E. is 8K words by 25 bits. 
It measures 0. 228 x 0. 165 x 0.044 m (9.0 x 6. 5 x 1. 75 in.) and weighs 1. 814 kg 
(4. 0 lb) ; average required operating power is 6. 0 watts. Minimum life expect- 
ancy ranges from 10 to 20 years. Though detailed environmental characteristic 
data are not available, it may be assumed such tungsten- wire memories should 
possess the same general features of the other plated-wire memories. This 
memory may be a great improvement in volumetric efficiency, price, and 
performance quality compared to conventional memories. Thier small size, 
higher speed, low power, and possibly the better environmental characteristics 
could make this memory particularly suitable for aerospace applications. 


B2. 8. 3 Honeywell Plated-Wire Memories 

Honeywell main frame memory intended for use in the aerospace environ- 
ment has TTL interface capability and al.27xlo” 4 m(5 mil) array. The 
electrical organization of this memory has the advantages of plated wire 
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characteristics. The plated- wire stack is organized in a configuration of 1024 
words by 16-bit. Each stack, containing eight memory boards, can be plugged 
into the main memory chassis. The modular expandability is accomplished 
by external interconnections of identical 8K main frame modules. General 
characteristics are given in Table B-18. Since Honeywell 1 s main frame, 
plated- wire memories are intended for aerospace applications, they should be 
considered as potential main frame memory for use in Spacelab. 


B2. 9 SUMMARY OF MEMORY SELECTION 

Memory selection studies and results are summarized in Table B-19. 

B3. 0 MASS MEMORY REQUIREMENTS 
B3. 1 INTRODUCTION 

Tape recorders have served as data storage units on spacecraft since 
the early days of the space program. Their primary purpose is to provide 
temporary storage of subsystem and scientific data until the spacecraft is in 
view of a telemetry 7 ground station in the NASA Space Tracking and Data Net- 
work. The recorded data are then transmitted to ground stations during the 
contact time available. For low- earth- orbit satellites, each ground station 
contact lasts only a few minutes. There may be several contacts per orbit, 
but there can be periods of several hours during which no contacts are 
possible, depending on the orbit. 

A Tracking and Data Relay Satellite System is planned which will provide 
contact times approaching 100 percent of the available time for each orbit. 

With essentially continuous communications between spacecraft and ground 
stations the storage capacity for onboard mass memory units may be reduced 
in a number of spacecraft applications. However, mass memory units will 
still be required for the following reasons: 

1. Communications coverage between the TDRSS and spacecraft will 
not be continuous, although nearly so. Also, the TDRSS may be required to 
time-share its capabilities with several spacecrafts in orbit at the same time. 
Limiting scientific data acquisition operations to time periods when com- 
munications contacts are possible is considered undesirable and may be unten- 
able for certain experiments. Thus, provisions must be made for storage of 
data during times when the spacecraft cannot or is not allowed to communicate 
with the TDRSS. 
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TABLE B-l 8. GENERAL CHARACTERISTICS OF HONEYWELL 
PLATED- WIRE MEMORIES 


Electrical 

• 8192 Words 

• 16 Bits Full Parallel 

• 1.0 /isec Read Cycle Time 
with 350 nsec Access Time 

• 1.0 Msec Write Time 

• Power 

Standby 12 W 
Read 19 W 
Write 21 W 

• NDRO 

• External Conversion to 
Read Only 

• TTL Interface Level 

• Expandable in SK 
Increments 


Mechanical 


• ATR Compatible 


Height 

0.194 m 


( 7. 62 in. 

Width 

0.121 m 


(4.75 in. 

Length 

0.33 m 


( 13. 0 in. 

Weight — 

6. 80 kg 


(15 1b) 

Easy Maintenance 


8 Plug-in Electronic 
Boards 

Plug-In Plated Wire 
Stack 


• Forced Air Cooling 
( Easily converted to 
conduction cooling) 


• Optional Mounting 
Provisions 


Environmental 

• Operating Temperature 

-55 to +71° C 

• Storage Temperature 

-62 to +95° C 

• Altitude 

To 70 000 ft 

• Vibration per MIL-E-54 00 
Curve IV 

• Shock 

15 g for 11 msec, 
each axis 


• Voltages +25 V ±2% 
+10 V ±2% 
+ 5 V ±5% 
+ 6 V ±5% 
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TABLE B-19. SUMMARY OF MEMORY SELECTION 


Memory and Storage Recommendation 


Technology 1 Category Intended 


Core Memory Main Frame Memory 


Plated Wire Main Frame Memory 


Off-the-shelf 


Ampex 1800 Series 


CDC ALPHA-1 Core Memories 


CDC 496 Main Frame Memory 


G.E. Tungsten Plated- Wire Memory 
Honeywell Plated Wire 


Being Developed 



Semiconductor Main Frame Memory 

Auxiliary Memory 


High Speed Buffer 


PMOS or NMOS LSI, RAM Memory 
of Advanced Memory Systems 

HRM-2048, Nonvolatile Amorphous 
Semiconductor of Energy Conver- 
sion Devices. 

Litton' s Militarized MOS Memory 


MNOS — Univac's Defense 
Systems 

MNOS — Weatinghouse 
CCD- MNOS Memory 

Rockwell Micro-electronics 

Silicon- on-Sapphirc 

Rockwell Micro-electronics 


Auxiliary Memory 
High Speed Buffer 


Auxiliary Memory 
High Speed Buffer 


Intermediate Storage 


Magnetic Bubble Intermediate Storage 


Auxiliary Memory 


IBM System/4 pi Mass Memory 


Univac's Mated-Film 
Memory 




CCD- MNOS Memory — 
Rockwell Mi cx‘ 0 - electronics. 


By Bell Laboratories, 
Rockwell Micro- electronics 
RCA, Monsanto 


DOT ram of Cambridge Memories 



Magnetic Tape 
Recorder and 
Beam Memory 


Intermediate and 
Mass Storage 


Ampex Terabit System, 
Grumman Masstape System, 
Precision Instruments UNICON 


Micro- Bit Beam- 
Addressable Storage 
System 
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2. Certain spacecraft are expected to have requirements for onboard 
processing of large amounts of sensor data. An example is the digital integra- 
tion of multiple exposure, low light level, astronomy data, such as these dis- 
cussed in References 24 and 25. 

3. Mass memory units will be required to buffer data between their 
sources and the communications transmitters. The reason for this is that source 
data are not likely to be generated at a rate or format for optimum transmission 
to ground stations. Thus, the data may be recorded at one speed and played 
back through the communications transmitters, either at a faster or slower 
speed, to make better use of the available communications facilities. 

This section concerns the incorporation of a mass memory into the 
Spacelab data management system. The DMS utilizes a computer-controlled 
data bus with peak data rates of 2 Mbs. The system configuration also provides 
for high data rates by switching high data rate sensor outputs directly to mass 
storage units, or directly to communications transmitters as required. Also 
discussed is the addition of a mass memory for use in onboard processing of 
scientific data by the DMS computer. There are manj^ possible ways of acquir- 
ing data from subsystem and scientific data sensors and routing these data to a 
mass memory. Six approaches, which the author considers as some of the more 
feasible ones, are discussed in the report. These approaches assume that data 
will be dumped from the onboard recorders through communications links to the 
ground. However, this function may not be required for Spacelab applications. 
Also, the mass memory is assumed to be one or more tape recorders. If 
solid-state mass memories are developed in time, they may be used in all 
recorder applications. No single tape recorder approach will satisfy all of the 
requirements for data storage. Some conclusions are drawn here as to com- 
binations of techniques which should be given further consideration. 


B3. 2 MASS MEMORY FUNCTIONS 

Mass memory units in future space systems may be required to perform 
several functions. These are: 

1* Store engineering and low- to- medium- rate scientific data for sub- 
sequent transmission to telemetry ground stations. For purposes of this study, 
these data would be acquired over the 2 Mbs data bus described in Reference 26. 
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2. Store high- rate scientific data for subsequent transmission to ground 
stations. These data rates could range from approximately 1 Mbs to as high 

as 100 Mbs. The data would be formatted prior to supplying it to spacecraft 
data management system for storage. 

3. Play back engineering and scientific data to ground stations at nor- 
mal, reduced, or accelerated rates, depending on the nature of the data and 
available communications facilities. 

4. Store and play back data to an onboard computer for onboard data 
processing purposes. This function is required for special experiment data 
processing functions, such as integrating signals from low-light-level image 
sensors to enhance their sensitivity. 

5. Store and play back data to onboard displays. This may be required 
only in manned spacecraft applications where the scientist would require access 
to historical data. The need for this function is not clearly established at this 
time. 


6. Store the vaiuous types of subsystem and scientific data described 
above for physical transportation to the ground. 


B3.3 MASS STORAGE DATA CHARACTERISTICS 
B3. 3. 1 Engineering Data 

Engineering data are those data necessary to monitor the state and 
performance of the various spacecraft subsystems. Typically, for telemetry 
purposes an engineering data point is sampled at a relatively slow rate, i. e. , 
in the range of a few samples per second to one sample every few seconds. 
Engineering data may be divided into two categories: 

1. Low Variance — This type of data remains relatively constant 
between data dumps and consists of data such as temperatures, voltages, and 
pressures. The primary interest in this type of data is that they are used to 
determine any abnormal conditions which indicate failures or potential failures 
and they provide data to engineering personnel for corrective action. These 
data also indicate the occurrence of discrete events, such as the firing of 
reaction jets or transition between light and dark protions of the orbit. 
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2. High Variance — This type of data continually changes between data 
dumps; it includes measurements such as control moment gyro gimbal angles, 
temperatures which vary as a function of orbital position, etc. A simple out- 
of-limit indication would not be appropriate for this type of data. 

High variance data may be recorded in a predetermined PCM telemetry 
format. Each measurement will occupy a specified position in the telemetry 
frame each time the telemetry frame is recorded. 

Requirements for recording low variance data for out-of-tolerance con- 
ditions or occurrence of discrete events may appear at random points in time. 
Thus, these data are not appropriate for fixed-format recording. Provisions 
must be made to identify discrete events and out-of- tolerance data points, 
along with associated data and the time that they occurred. This type of data 
may be recorded between telemetry frames when required. 


B3. 3. 2 Scientific Data 


Scientific data from various experimental and operational sensors are 
expected to vary widely in their data rates and format characteristics. For 
purposes of this report, scientific data are categorized according to means by 
which they may be accommodated, as described below. 


B3. 3. 2. 1 Data Bus Compatible 

Scientific data which are compatible with the generalized data manage- 
ment system data bus [ 26] may be accommodated directly by the data bus. 
Limiting factors are the number of scientific data measurements and their 
associated data rates. The capability to accommodate scientific data via the 
data bus will have to be addressed separately for each spacecraft since the data 
bus serves both subsystems and experiments, and subsystem requirements will 
vary significantly between spacecraft. 


B3. 3. 2. 2 High Data Rates 

Scientific data whose rates exceed the data bus capability will require 
accommodation by high- data- rate mass memory units. These data rates will 
range from approximately 1 Mbs to as high as 100 Mbs in the future. These data 
would be formatted by special purpose devices before providing them to the mass 
memory unit. 
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B3. 3. 2. 3 Special Format 


The data bus may accommodate special format scientific data, provided 
that such data does not exceed the data bus speed capabilities. The special for- 
mat would include larger digital words for increased accuracy and resolution. 

If the special format data are compatible with data bus operations, the 
data could be supplied to the mass memory through either the discrete input 
channels or the serial input channels of the DIU. If the data rates are not com- 
patible with the data bus speed, the data could be supplied to the mass memory 
through the DECU [26] . 

B3.4 GENERALIZED DATA MANAGEMENT SYSTEM CHARACTERISTICS 

Preliminary generalized data management system characteristics are 
extracted from Reference 26 and are summarized in the subsections that 
follow. 


B3.4.1 Data Management System Configuration 

The baseline data management system configuration for the purposes of 
this study is illustrated in Figure B-l. There are four deviations from the 
system described in Reference 26. These are: 

1. Addition of lines from tape recorder outputs through the DECU to 
communications transmitters. This will enable the switching of selected tape 
recorders to one or more of the communications transmitters. This capability 
is not required for all spacecraft. In those where the capability is not required, 
the provisions for sending recorder outputs to ground stations via the com- 
munications link may be deleted. 

2. Inclusion of data- bus -compatible experiments in the same category 
as a user subsystem. This recognizes that the data bus can serve certain 
experiments as well as user subsystems. 

3. Addition of a wide-band data line from the DECU to the control and 
display subsystem for display of direct or recorded video data. (Only applicable 
to spacecraft which have onboard control and display subsystems. ) 

4. Addition of provisions for an optional auxiliary memory for onboard 
data processing, as discussed in Section B3. 5. 6 of this report. 
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Figure B-l. Baseline data management system configuration. 














The computer subsystem includes the central processor unit, main 
memory, and input/output processor. Their characteristics are summarized 
below: 


1. CPU 


a. General purpose. 

b. Parallel operation. 

c. Stored program capability. 

d. Either 16- or 32-bit instructions and data words. 

e. At least 400 KADS. 


f. Fixed- and floating-point arithmetic. 

g. Microprogrammed. 

2. Input/Output Processor 


a. Provides interface between CPU and main memory and the 

CIU. 


b. Direct memory access. 

c. Parallel channel interfaces with one to three CIUs. 

d. Provides optional parallel interface with computer auxiliary 
memory. (This feature not included in references.) 

3. Main Memory 

a. Modular, up to 64K word capacity. 

b. 1 psec cycle time (approximately) . 
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B3.4.3 Data Bus Subsystem 


The data bus subsystem includes the computer interface unit, up to 32 
data interface units, and associated interconnecting cabling. The data bus uses 
separate supervisory and reply, twisted, shielded pair cables operating at 2 Mbs. 
The supervisory line is synchronous while the reply line is asynchronous. Only 
the CIU issues commands and data on the supervisory line. The DIUs transmit 
to the CIU and other DIUs on the reply line. The DIUs provide the interface 
between the data bus and user subsystems or compatible experiments. Up to 
three data bus subsystems may interface with the computer subsystem. The 
additional components may be used to expand the capacity of the system or to 
improve system reliability through redundant elements. 


B3. 4. 3. 1 Computer Interface Units 

The CIU performs the following functions (see Figure B-2 for pre- 
liminary block diagram) : 

1. Controls all traffic on data bus. 

2. Issues commands and data to DIUs. 

3. Receives data for computer processing. 

4. Receives data for subsystem errors, and provides indications to 
the computer subsystem. 

5. Performs serial-to-parallel and parallel-to-serial conversions 
between the computer subsystem and data bus elements. 

B3.4.3.2 Data Interface Units 

The DIUs have the following capabilities: 

1. Modularity to provide the following interfaces with user subsystems: 

a. Discrete Inputs: 0 - 128 in increments of 16; 0-22 volts, 

b. Discrete Outputs: 0 - 128 in increments of 16; 0-28 volts. 

c. Analog Inputs: 0 - 128 in increments of 16; 0 - 5 volts. 
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TO DMS TAPE 
RECORDERS VIA 
THE DECU 


Figure B-2. CIU block diagram. 













d. Analog Outputs: 0 - 4 in increments of 1; 0 - 5 volts. 

e. Record In: 0 - 8 in increments of 1; 0 - 5 volts. 

f. Record Out: 0 - 8 in increments of 1; 0 - 5 volts. 

2. Limit checking of analog inputs. 

3. 8-bit resolution for analog inputs and outputs. 

4. Record In and Record Out data rate of 2 Mbs. 


B3.4.4 Recording Subsystem 

The recording subsystem consists of the DECU and one or more record- 
ers. These recorders are generally considered to be magnetic tape units 
similar to those customarily used in space application. However, they may be 
replaced by advanced technology recorders such as the magnetic domain (bubble) 
memory devices currently in an advanced development stage. The purpose of 
the DECU is to switch data from the various sources to the recorder selected 
and to switch data being read out of a selected recorder to its destination. The 
recorder output data destination will usually be a communications transmitter 
or a control and display unit. Different kinds of recorders may be used to match 
the characteristics of the data to be recorded. Figure B-3 illustrates the 
recording system configuration and its interface. 


B3.4.4.1 Data Exchange Control Unit (Fig, B-4) 

The DECU will be used to handle high data rates, special formats, or 
long streams of data which may not be carried on the data bus. Its character- 
istics are: 

1. Cross switching of 20 inputs and 20 outputs. 

2. Bandwidths up to 60 MHz, nominal. 

3. Activation time — 1 msec. 

4. Built-in switch status monitor. 
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Figure B-3. Recording subsystem configuration and interfaces. 


B3.4.4. 2 Recorders 

Characteristics of the recorder units are to be determined and will vary 
according to specific spacecraft applications. 
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Figure B-4. Data exchange control unit. 


B3.4. 5 Communications Subsystem Interfaces 

Data rates and bandwidth s of signals from the mass memory units to the 
spacecraft communications transmitters must be compatible with the com- 
munications link capabilities. These data dump signals should be optimized to 
permit the transmission of the maximum amount of data in the least amount 
of time, consistent with allowable noise and error rates. Since there may be 
more than one mass memory and more than one communications transmitter, 
provisions must be made to select the memory units and transmitters to be 
used and select the required switching between them. The DECU may be used 
for switching, or simpler devices may be used if the switching job is not com- 
plex. Spacelab may require the dumping of some recorded data through the 
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Space Shuttle communications transmitters. Representative bandwidths and 
data rates for the STDN, TDRSS, and Space Shuttle are summarized below: 

1. Spacecraft to STDN via Shuttle communications: 

a. One 25 kbs operational telemetry link. 

b. One 3- MHz TV link. 

c. One 256-kbs science data link. 

d. One 32-kbs duplex voice link. 

2. Spacecraft to TDRSS via Shuttle communications: 

a. One 25-kbs operational telemetry link. 

b. One 4- MHz TV link or up to 50 Mbs data. 

3. Spacecraft to STDN via direct link (preliminary post-1975 data) . 

a. Up to four 1-Mbs telemetry links. 

b. Receivers telemetry information bandwidths up to 20 MHz. 

4. Spacecraft to TDRSS via direct link (preliminary post-1978 data) . 

a. Two single-access S-bands, up to 1 Mbs each at 30 dBm EIRP 9 , 

BER = 10 5 . 

b. 20 multiple- access S-bands, up to 40 kbs each at 30 dBm EIRP, 

BER = 10 5 . 

c. One single-access Ku-band, up to 100 Mbs at 50 dBm EIRP, 

BER = 10 5 . 


9. EIRP — effective isotropic radiated power. 



B3. 5 CANDIDATE MASS STORAGE CONCEPTS 


There are two important considerations in the design of a data acquisition 
system: 

1, The characteristics of the data to be acquired, either for recording 
purposes or transmission direct to ground stations. 

2. The process for obtaining the data from their various sources and 
formatting these data for recording and transmission. 

Table B-20 illustrates means of recording three basic types of data by the base- 
line data management system. (The data types were discussed in Section B3. 3. ) 
It is essential to record an indication of the time that each block of data was 
taken so that the time history of the data can be reconstructed by ground-based 
computers. 

Formatted experiment data may be time- tagged and recorded directly 
into a dedicated experiment data recorder. 

High variance engineering and experiment data (whose values are not 
expected to remain within sufficiently narrow ranges to utilize the data manage- 
ment system limit checking capabilities) will be sampled periodically. These 
data may be time-tagged, their identity recorded, and merged with other data 
being handled b 3 ^ the data management system. 

Low variance data (which are expected to remain within narrow limits 
such that limit checking techniques are applicable) need not be recorded unless 
an abnormal condition is found to exist. If a measurement is found to be out of 
its expected range, the computer must time-tag and identify the measurement 
so tli at ground personnel may examine the situation and take appropriate cor- 
rective action. A similar process is required to record the occurrence of 
discrete events as indicated by a change in discrete inputs to the DIUs. 

Since low variance data are largely predictable, they are prime can- 
didates for extensive data compression. Figure B-5 presents a simple case 
where low variance data may be compressed by a factor of 43 200:1. (Com- 
pression ratio is defined here as the number of bits in the total number of 
measurements divided by the number of bits recorded or transmitted for these 
measurements.) In this case it is assumed that a single data point would be 
sampled once per second over one orbit period. If all of the data were 
recorded this data point would require 43 200 bits of storage. However, if no 
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TABLE B-20. BATA RECORDING OPTIONS 


Data Type 

Recording Type 

Data Recorded 

Formatted Experiment Data 

Fixed Format 

Time and Prescribed Sequence 
of Data Words 

High Variance Engineering 
and Experiment Data Whose 
Values Do Not Remain Within 
Narrow, Prescribed Limits 

Variable Format 

Time Format Identification and 
Prescribed Sequence of Data Words 
Within Format 

Low Variance Data Which 
is Expected To Remain Within 
Prescribed, Narrow Limits 
During Normal Operation 

Variable Format 
With Limit Checking 
Type of Data 
Compression 

Time and D1U Address, Word 
Address, and Data For Any 
Nonnormal Conditions 


LIMIT CHECKING 


• 

SAMPLE MEASUREMENT ONCE PER SECOND 


• 

DATA DUMP ONCE PER ORBIT 


• 

INDICATE NORMAL/ABNORMAL CONDITION FOR ENTIRE ORBIT 

• 

5400 SEC/ORBIT 


• 

8 BITS/WORD 


COMPRESSION RATIO - 8 x 5400 BITS SENSED _ 

1 BIT TRANSMITTED 

43 200:1 {IF NORMAL) 

HIGH-LOW-AVERAGE 


• 

COMPUTER DETERMINES HIGH, LOW, AND AVERAGE VALUE BETWEEN 
DATA DUMPS 

COMPRESSION RATIO - 8 x 5400 BITS SENSED 

3x8 BITS TRANSMITTED 

= 1800:1 


Figure B-5. Data compression examples, low variance data. 
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data were recorded except a single bit to indicate that the data point did not 
exceed its limits during the time since the last data dump (assumed to be 5400 
sec for one orbit) , then the data compression ratio is 43 200:1. If the data 
point goes out of its limits, the out of limit data will be recorded and a some- 
what smaller compression ratio will result, depending on the length of time 
that the data point is out of limits. 

Another data compression technique applicable to low variance data is 
for the computer to process each measurement to determine the high, low, 
and average (or sum) of all samples since the last data dump. This would 
provide the ground station with additional data concerning the measurement, 
but it requires 3 bytes storage in computer memory for each data point so 
treated. For the example shown, a compression ratio of 1800:1 may be expect- 
ed. Compressing low variance data will reduce the amount of recording medium 
and communications bandwidth requirements, thus making capabilities available 
for data which cannot be readily compressed. 

The numbers of low and high variance data points will be dependent on 
the particular payload application. Table B-21 contains a summary of Space- 
lab subsystem measurements and commands. The numbers of low and high 
variance data points are the author’s estimate, based on the assumption that 
data points sampled once per second or less may be appropriate for limit- 
checking. The estimate of the number of low variance data points is apt to be 
on the high side, since data points sampled at slow rates are not automatically 
in the low variance data category. Data sampled more often would likely be 
used in control loops and would be susceptible to wider variation. Each measure- 
ment should be examined to anticipate its expected range during normal oper- 
ations. In some cases it will be necessary to perform ground laboratory tests 
and obtain data from on-orbit measurements before the normal range of oper- 
ation can be determined. This is particularity true in the case of time- varying 
temperature measurements which are related to the sun angle and orbit param- 
eters. Thus, where limit checking is used, provisions must be made for 
changing the limits on orbit to accommodate unpredictable and time variable 
ranges of normal operations. 

The baseline DIU has the capability for detecting discrete events through 
changes in the status of its discrete inputs. When discrete events occur it will 
be necessary in many cases to record the identity of the event and the time that 
it occurs. This requires that the data management system periodically sample 
the discrete input change status registers in the DIUs. The sampling rate for 
changes in discrete inputs will depend on the accuracy requirement for deter- 
mining the time that the events occur. Typically, this accuracy is about 100 
msec, which would require the sampling of the status or discrete inputs at 
least 10 times per second. Recording discrete input changes only should result 
in a significant saving in the amount of data stored in the mass memory. 
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TABLE B-21 . SPACELAB SUBSYSTEM MEASUREMENT AND COMMAND LIST SUMMARY 



Subsystem 

Measurement 
( samples/ seel 

Stabilization 
& Control 

Data 

Management 

Electrical 

Power 

Environmental Control 
and Life Support 

Thermal Control 
and Structure 

Low Variance 
Data' 1 

High Variance 
Data 

Total 

Analog Inputs 

1 



70 

;J2 

3S 

1 Oil 


160 

i 

(17 

i:i 


Li 


03 


fi.’i 

10 

27 



77 



104 

104 

10(1 

l 






1 

1 

Discrete Inputs 
(0 

i r> 

7”) 

105 

042 

;>2 

570 


570 

Discrete Outputs 
(1) 

1 1 

10 

IS 

07 

16 

102 


192 

Heeord Outputs 

(D 

a 

25 



M 


42 

42 

lleeord Inputs 
(J) 

5 

4 



5 



14 


a. Estimates of low variance data candidates for Limit: 

Analog Inputs — 262 
Discrete Inputs — 570 
Discrete Outputs — 102 











































Figure B-6 illustrates representative formats for recording high and 
low variance data with a data bus type of data acquisition system. High variance 
data may be recorded periodically in fixed formats, so it is not necessary to 
separately identify each data word or series of data words in the telemetry 
frame. There may be several types of fixed format frames used in the same 
system. These could be used to accommodate the sampling of different data at 
different sampling rates (i. e. , some data at 10 times per second, other once 
per second, etc.) or could be used to separate the types of data according to 
various subsystem and experiment data categories. This separation may facil- 
itate reconstruction of data at ground-based data reduction facilities. The first 
word in the fixed format frame is used to identify the beginning of the record 
and the type of frame. The second word indicates the time that the record was 
made. A fixed number of data words will follow, the number and sequence being 
controlled by the digital computer program. When all data words are recorded, 
a unique end-of- record identification is recorded. 

Low variance data may be recorded randomly between fixed format 
frames when required. The first word in the record identifies the beginning 
of the record and the type of frame. The second and third words identify the 
data specifically through the DIU address, operation code, channel address, 
and word count. The fourth and subsequent data words indicate the time that 
the record was made. A unique end- of- record word is recorded after all data 
are recorded. 

Options for processing data from their sources to recorders are discus- 
sed in the following sections. 


B3. 5. 1 Option 1 — Computer Control With CIU Telemetry Formatter 

The flow of data from sources to recorders to communications trans- 
mitters is illustrated in Figure B-7. In this option the computer and its asso- 
ciated CIU controls all data bus traffic for data used for telemetry purposes as 
well as subsystem and experiment control purposes. The baseline system can 
accommodate peak data rates of 2 Mbs in this mode of operation. The average 
data rate available for recording will be somewhat less, depending on the mix 
between control and telemetry functions. The data flow is summarized as 
follows: 
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PERIODIC, FIXED FORMATS 
(HIGH VARIANCE DATA) 





1 . 

BEGINNING ANO TYPE OF FRAME 


2. 

TIME 


3. 

FIRST DATA WORD 



DATA WORD 



DATA WORD 


M. 

LAST DATA WORD 


N. 

END OF RECORD 



RANDOM, VARIABLE FORMATS 
(LOW VARIANCE DATA) 


1. BEGINNING AND TYPE OF FRAME 

2. DIU ADDRESS, OP CODE, CHANNEL ADDRESS 

3. WORD COUNT 

4. TIME 

5. FIRST DATA WORD 

DATA WORD 
DATA WORD 

M. LAST DATA WORD 

N. END OF RECORD 


Figure B-6. Representative telemetry formats 





1. Signals from experiment or subsystem sources are conditioned in 
the experiment or subsystem to a standard signal acceptable by the DIU. 

2 . Source data are multiplexed in the DIUs and transmitted over the 
data bus to the CIU in serial form at a 2 Mbs rate. (One source is a time unit 
which is used to indicate what time a block of measurements were taken such 
that a time history of the recorded measurements may be reconstructed by 
ground based computers. ) 

3. The data may be formatted in the telemetry formatter section of 
the CIU until a block of telemetry data is accumulated in a buffer unit. This 
block is then transmitted to a mass storage unit, where it is held until time 
to dump the contents of the mass memory to ground stations via the communi- 
cations links. The recorders are controlled through computer software and 
control signals routed through DIU discrete output channels, 

4. When it is time to dump data from recorders to ground stations, 
the computer controls the switching of channels in the DECU so as to route the 
right recorder output signals to the right communications transmitter. (Note: 
Spacelab missions may not require a recorder dump via the communications 
link) . 


5. In some cases it may be desirable to dump data directly from the 
telemetry formatter to the communications subsystem. This may be done by 
routing the telemetry output of the CIU through the DECU to the communications 
transmitters. 



•MULTIPLE UNITS 

Figure B-7. Option 1 — computer control emphasis 
with telemetry formatter in CIU. 
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B3. 5. 2 Option 2 — Computer Control With Computer Formatter 

This option is similar to Option 1 except that telemetry data formatting 
is accommodated by the computer and its main memory. The data flow is 
illustrated in Figure B-8 and is summarized below: 

1. Signals from experiment or subsystem sources are conditioned in 
the experiment or subsystem to a standard signal type or range acceptable by 
the data interface unit. 

2. Source data are multiplexed in the DIUs and transmitted over the 
data bus to the computer interface unit in serial form at a 2 Mbs rate. 

3. Data are converted from serial to parallel form in the CIU and 
supplied to the computer for processing. In the computer, several different 
functions may be performed on the data, such as: 

a. The data may be formatted for telemetry purposes. Direct 
access from the CIU through the computer's I/O processor to the computer's 
main memory may be considered for this purpose. 

b. The computer may process the data for experiment or sub- 
system control functions. Typically, the computer would process attitude and 
rate sensor data to determine signals to be sent to the attitude control torquers 
for attitude control purposes. 

c. The computer may compress some of the data so as to reduce 
mass memory storage requirements, and data communications requirements. 

d. The computer may perform special computations on experiment 
data, sue as digital filtering and integration of signals from low-light-level 
image sensors. 


e. After data are processed in the computer, they are returned to 
the CIU where they are converted from parallel to serial form and transmitted 
over the data bus to one of the DIUs. 

4. If the data are to be used for subsystem or experiment control pur- 
poses, the control signals are routed through a DIU to the desired control 
devices. 
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5. If the data are to be recorded, the data are routed to a recorder 
through one of the DIU channels or through a DECU channel. When it is time 
to dump data from recorders to ground stations, the computer controls the 
switching of channels in the DECU so as to route the right recorder output 
signals to the right communications transmitter. 

6. In some cases it may be desirable to dump data directly from the 
computer memory to the communications subsystem. This may be done by 
routing the computer memory data through the CIU and to a DIU or DECU to 
the communications transmitter. 


(i) 



•MULTIPLE UNITS 

NOTE (1) THIS DIU COULD BE REPLACED WITH A DECU CHANNEL 


Figure B-8. Option 2 — computer control emphasis 
with computer formatter. 
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B3.5.3 Option 3 - DlU-to-DIU Transfer 


In the DIU-to-DIU transfer, all data bus traffic is under control of the 
computer and its associated computer interface unit. Data flow using this 
technique is illustrated in Figure B-9 and is summarized below: 

1. Conditioning and multiplexing of source signals is the same as for 
Option 1. 

2. The computer and CIU set up the transmitting and receiving DIUs 

to enable the sending DIU to transmit data and the receiving DIU to receive data. 

3. The transmitting DIU sends its data over the data bus reply line to 
the CIU . 


4. The data are temporarily held in the CIU for three word times, and 
then transmitted over the supervisory bus to the receiving DEJ. 

5. The data are passed through the receiving DIU to a buffer storage 
unit. After a block of data is accumulated in the buffer storage unit, it is then 
dumped into the recorder unit. 

6. Playback to communications transmitters is through the DECU as 
in previous options. 



♦MULTIPLE UNITS 
R - REPLY 

S - SUPERVISORY BUS 

RO - RECORD OUTPUT LINES 

Figure B-9. Option 3 — DIU-to-DIU data transfer. 
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B3. 5.4 Option 4 — Decode Commands for Record 

In this option, commands originating in the CIU and transmitted over 
the supervisory bus are decoded in a tape recorder interface unit (TRIU). 

The decoding indicates that data are to be recorded from supervisory bus or 
the reply bus, and these data are allowed to pass through the TRIU to the buffer 
unit for recording data (see Figure B-10). This technique requires the addition 
of bits in the supervisory command words. One possible format is to replace 
currently unused bits in the word count (WC) word with bits which indicate 
that the next data block on the supervisory bus or the reply bus is to be 
recorded. This format is illustrated in Figure B-ll. Since there will likely 
be more than one recorder, it is also necessary to identify which recorder is 
to be used. Three bits could be used to control the data for up to seven 
recorders, with one bit combination reserved for the case where data are not 
to be recorded. Note that it is necessary to decode the operation code in the 
supervisory bus A word in order to know which bus is to supply data for 
recording. The technique may also be used to control the transmission of data 
directly from the data bus to communications transmitters where direct com- 
munications to ground stations is desired. Two or three additional bits in the 
supervisory bus WC word would be required for this purpose as indicated in 
Figure B-ll. 



•MULTIPLE UNITS 

TRIU - TAPE RECORDER INTERFACE UNIT 

Figure B-10. Option 4 — decode commands for record. 
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WORD 

SYNC 

BUS 

CODE 

PREFIX 

INFORMATION BITS 

WS 

Cl, C2 

0 1 2 3 4 5 

6 7 8 

9 10 11 

12 13 14 15 

P 

1 

1 1 

CHANNEL COUNT 

RECORDER 

NUMBER 

TRANSMITTER 

NUMBER 

SPARES 



Figure B-ll. Supervisory bus word count word format. 

The data flow is illustrated in Figure B-10 and is summarized below: 

1. Data are conditioned, multiplexed, and put on the data bus in the 
normal manner, as described in steps 1 and 2 of Option 1. 

2. Commands issued from the CIU to the supervisory bus are encoded 
to identify which blocks of data are to be recorded and which recorder is to be 
used. 


3. Logic circuitry within the TRIU decodes the supervisory bus com- 
mand and, when a record command is recognized, the TRIU gates data from 
die next block of data on the supervisory bus or the reply bus to a buffer unit. 

4. When the buffer unit is filled, the data are dumped into a tape 
recorder unit, where they are stored until time for playback. 

5. Playback is accomplished by switching the output of the selected 
recorder through the DECU to a communications transmitter. 


B3. 5. 5 Option 5 — Wide Band Data Storage 

Wide band data storage equipment will be required for storing data whose 
rates are beyond the capability of the data bus. These data rates will range 
from approximately 1 Mbs to as high as 100 Mbs in the future. Since there may 
be more than one high data rate sensor, provisions must be made to switch 
various high data rate sensor outputs to one or more wide band recorders. 

Data flow for storage of wide band data is illustrated in Figure B-12 and is 
summarized below: 


197 


















1. High data rate source data is formatted in the experiment or sub- 
system supplying such data. 

2. Formatted data from high date rate sensors will be supplied to the 
DECU for routing to a wide band recorder. If there is more than one high data 
rate sensor, the outputs from the various sensors either may be switched 
sequentially to a wide band recorder or multiple wide band recorders could be 
used for simultaneous recording of data from multiple sensors, 

3. When time for playback, the selected recorder output will be 
switched through a DECU to the desired communications transmitter. 

4. For spacecraft with an onboard display, the sensor data either could 
be switched directly or the recorder output could be used for onboard monitor- 
ing purposes. 



•MULTIPLE UNITS 

Figure B-12. Option 5 — wide band data storage. 


B3, 5. 6 Option 6 Auxiliary Memory for Computer Processing 

It is anticipated that there will be some requirements for onboard com- 
puter processing of mass memory data. One example is the digital integration 
of low- light- level sensor outputs for image and spec tro graphic data in astronomy 
observation. The purpose of the integration is to reduce noise effects arising 
within the sensor. Two techniques describing the use of a digital computer in 
processing this type of data are described in References 24 and 25. 


198 





A magnetic domain (bubble) memory is ideal for use as an auxiliary 
memory. However, none currently exist which can meet space program , 
requirements. Some characteristics projected for 1978-1980 are: 

1. Capability — Total capacity (per unit) 100M bits. 

2. Data Hates — Up to 1M words/sec. 

3. Weight — 30 lb. 

4. Power — 20 watts. 

5. Volume — 0.3 ft 3 . 

A technique for using advanced technology magnetic domain (bubble) memory 
as an auxiliary memory is illustrated in Figure B-13 and is summarized below: 

1. Data from selected experiment sensors is switched through a DECU 
to the auxiliary memory unit. This unit will have built-in controls for storing 
data in the proper format and sequence. 

2. The data are processed through the CIU and digital computer accord- 
ing to experiment data processing requirements. Two basic approaches for 
integrating experiment image data are: 

a. A complete block of experiment data could be read into the 
auxiliary memory, and the computer could later add corresponding elements 
of this block to a block of data already in storage. 

b. Data from each pixel could be added to data previously stored 
in the auxiliary memory as data are received from the sensor. 

Option a uses twice as much data storage space as option b but relaxes the 
requirements for the computer to integrate data in real time. Real-time proc- 
essing may present problems for cases where data arrive from the sensor 
at a high rate, perhaps faster than 10 Mbs. 

3. Since there may be several auxiliary memory units in the same 
system, the outputs of the auxiliary memory units are switched through the 
DECU to the communications transmitters for data dumping. 
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AUXILIARY 

memory 



•MULTIPLE UNITS 


Figure B-13. Option 6 — auxiliary memory for computer processing. 


B3 . 6 CONCEPT COMPARISON 

Options 1 through 4 are various ways in which data could be recorded 
using the data bus. Option 5 is applicable when the data to be recorded cannot 
efficiently be handled by the data bus. Option 6 is applicable when large amounts 
of data are to be processed onboard. Several options have desirable features 
which may be considered for incorporation in the generalized data management 
system for different modes of operation. 

Options 1 (computer control with CIU telemetry formatter) and 4 (decode 
commands for record) may be similar options, depending on the mechanization 
of the telemetry formatter and the tape recorder interface unit. (Details of the 
MSFC telemetry formatter in the CIU are not available at the time of writing 
this report. ) Each option is capable of recording high variance data in a pre- 
determined telemetry frame format, as well as recording abnormal conditions 
or discrete events as determined by data bus and computer operations. The 
efficiency of these options in terms of number of data bus transactions and 
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computer operations is potentially good. Data for processing and recording 
could be acquired simultaneously when required, and data need flow over the 
data bus only once where data are to be recorded. The basic difference between 
Options 1 and 4 is the location of control logic and buffer storage hardware. 
Several variations may be considered. The buffer storage units may be either 
separate units, combined with mass memory units, or included in the CIU. The 
control logic could be either a separate unit or contained in the CIU telemetry 
formatter in the baseline generalized data management system. 

Option 2 (computer control and formatting) is appropriate when data are 
to be processed before storing in the mass storage unit. The processing may 
be for data compression, filtering, or special computations as dictated by 
experiment requirements. Option 2 is less efficient than Options 1 and 4 in that 
data must pass over the data bus twice before storage in the mass memory 
unit. However, the ability to compress data may partially overcome this loss 
in efficiency. An improvement in Option 2 would be to route processed data 
from the computer through the telemetry formatter or TRIU for recording in 
the mass memory, rather than routing this data over the data bus. 

Option 3 (DIU-to-DIU transfer) is somewhat more efficient than Option 2 
in that data to be recorded do not have to pass through the computer. However, 
data do have to be handled twice on data bus, once on the reply line, and once 
on the supervisory line. Additional logic within the CIU will be required to 
control the DIU-to~DIU operations. 

Figure B-14 illustrates the composite data flow for Options 1, 2, 5, 
and 6. This composite may be considered a candidate for the generalized data 
management system. Its characteristics are: 

1. The data bus may be used to acquire subsystem and experiment 
"data bus compatible" data for recording and to direct transmission of telem- 
etry data. 


2. Much of the same hardware may be used for telemetry data acquisi- 
tion, and subsystem and experiment control purposes. 

3. The system is flexible in that DIU, buffers, recorders, communi- 
cations transmitters, etc. , may be added or deleted to conform with require- 
ments of the system application. 

4. The types of recorders and communications transmitters may be 
selected according to mission requirements. 


201 




•MULTIPLE UNITS 


Figure B-14. Composite data flow. 
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5. The system makes efficient use of the data bus in that the data bus 
does not have to handle the same data more than once from source to recorder. 

6. Data dump via communications transmitters may be performed at 
optimum communication rate for those applications requiring a data dump, 

7. Data processing may be performed on data acquired via the data 
bus or on special wide band sensor data. The auxiliary memory is used to 
interface with wide band sensors and to store any large amounts of data to be 
processed by the computer. 

8. Data compression techniques may be employed where appropriate. 

9. For applications with onboard displays, data may be displayed via 
the data bus. Wide band (television, for example) or special format sources 
may be displayed by switching through the DECU. 

10. For those applications using onboard displays, flexibility exists 
to display data from a variety of sources, including the data bus, wide band 
sensors, and recorder outputs. 

11. Data may be transmitted directly to ground stations without the 
necessity of recording it first. 


B3. 7 MASS MEMORY FUNCTIONAL AND INTERFACE REQUIREMENTS 

One of the problems that must be addressed in using a tape recorder 
with the data bus is that of matching the data rates from the data bus to the 
data rates of the recorder. Typically, the data to be recorded will arrive at 
rates of 2 Mbs for periods of up to a few milliseconds for each burst of data. 
For example, one condition might be to record the outputs of all 128 channels 
of each of 32 DIUs once per second. This would total 8 bits x 128 channels x 
32 DIUs, or 32 768 bits. These bits would arrive from the data bus in approx- 
imately 20 000 psec. Since these data would only be taken once per second, 
the recording of these data could be spread out over a 1-sec time period. This 
relatively low average recording rate would reduce tape recorder design 
requirements. 
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The tape recorder could be run continuously to accommodate the average 
data rate, or the recorder could be run incrementally to record 32 768-bit block 
of data in each increment. A buffer memory is required in either case. (Note 
that a buffer memory would not be required if a bubble memory were used as a 
mass memory device. ) The incremental drive type of tape recorder has an 
advantage over the continuously running type in that the number of increments 
per second can be adjusted to match the arriving data rate. Since the average 
arriving data rate is not likely to be constant, this would significantly improve 
the recording efficiency in that the recorder only runs when data are to be 
recorded. With the continuously running recorder, the recording speed must 
be compatible with the highest expected average data rates, which may result 
in significant amounts of unusable tape space. The space between each block 
of data will decrease the recording efficiency if the blocks of data are too small. 
This space may be from 6. 35 x lo” 1 2 3 to 0.1524 m (0. 25 to 6 in. ) long depending 
on the tape drive design and tape speed. Recording efficiency is important for 
minimizing the amount of tape required, but becomes even more important if 
the data are to be played back over a communications link to the ground. 
Improving recording efficiency will enable the playback of data to the ground 
at higher data rates, lower bandwidths, shorter transmission time, or lower 
bit error rates, depending on communications requirements and capabilities. 


B3. 7. 1 Buffer Memory Functions 

The buffer memory provides the interface between the tape recorder 
and the telemetry formatter for recording of data from the data bus. The 
buffer memory could be packaged with the telemetry formatter, with the tape 
recorder electronics, or as a separate unit. A candidate list of functions 
required for the buffer memory is described below: 

1. The buffer memory must be able to recognize the presence of 
arriving data and synchronize with this data. 


2. The buffer must store the arriving data in sequence. 

3. The buffer must be able to simultaneously store arriving data and 
supply data to the tape recorder; the buffer would be divided into two halves 
for this purpose. Switching between storing and readout is required. 
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4. The buffer must be able to recognize any overflow conditions and 
avoid the overwriting and resulting loss of previously stored data which had 
not yet been transferred to the tape recorder, 

5. The buffer may encode data being supplied to the tape recorder. 
This would include the assignment of bits and bytes to selected track locations, 
as well as converting the data to a Miller (delayed modulation) to improve 
recording performance. Similarly, the buffer may decode data from the 
recorder to a standard PCM code during playback, 

6. The data would be read out to the recorder on a first- in/first- out 

basis, 

7. If the tape recorder is operated incrementally, the buffer must 
provide start signals indicating the presence of data and stop signals indicat- 
ing the completion of a block of data. The buffer memory output would have 
to be synchronized with the start and stop of the tape drive. 


B3. 8 CONCLUSIONS AND RECOMMENDATIONS 

The results of a preliminary analysis of the requirements, functions, 
interfaces, and candidate means of implementing mass storage units into the 
MSFC Spacelab data management system have been presented. Some tentative 
conclusions are: 

1* Mass storage units, such as tape recorders or magnetic domain 
components will continue to be required in future spacecraft. The availability 
of the TDRSS does not negate the requirement for mass memory units. 

2. Mass storage units may be used in several different types of 
applications. One type will be to record engineering and data bus compatible 
scientific data, while other types will be the recording of special format and 
wide band data generated by non- data- bus-compatible experiments. Still 
another type is the storage of data for onboard processing of experiment data 
in special applications. 

3. If tape recorders are employed, different designs may be required 
for data bus and non- data- bus- compatible applications. If magnetic domain 
memories become available for space applications, consideration should be 
given to using the same type of magnetic domain memory in all mass storage 
applications. 
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4. A variety of means of implementing mass storage units into the 
generalized data management system should be given further consideration* 
The author has presented seven options and has outlined an approach using 
four of these options. Further effort is required to develop details for 
implementing mass storage units in the generalized data management system. 

5. Development of magnetic domain mass storage units to replace 
tape recorders and to serve as auxiliary memory units for onboard processing 
applications should be encouraged. The use of magnetic domain memories 
instead of tape recorders is expected to result in significant reliability, 
weight, power, and performance advantages. 


206 



APPENDIX C. DATA ACQUISITION 
AND DISTRIBUTION SUBSYSTEM 



Cl.O DATA BUS POWER CONSUMPTION 


The power consumption of a digital data bus depends on its complexity, 
operational speed, and the type of integrated circuits used* For buses of the 
same complexity, the operational speed places certain constraints on the type 
of integrated circuits which may be used. In this study, two buses were con- 
sidered, one which has an operational speed of 1 MHz and another with a speed 
of 10 MHz. 

There are three general types of integrated circuits: CMOS (comple- 
mentary metal oxide semiconductor) or MOS (metal oxide semiconductor) , 

TTL (transistor-transistor logic), and ECL (emitter coupled logic). ECL 
type circuits will not be covered because they are generally used for high fre- 
quencies (750 MHz) and they use much more power (65 to 115 mW/gate) . The 
TTL circuits will be considered for both cases. The CMOS will only be con- 
sidered for the 1 MHz bus because an operational speed of 10 MHz would be 
pushing the state-of-the-ax’t. 

The CMOS and TTL type circuits have different power dissipations per 
gate as can be seen in Table C-l. The dissipation in the CMOS circuits depends 
on both the operating frequency and the supply voltage. The dissipation in the 
TTL circuits depends mainly on this type. For most cases, a TTL’s dissipa- 
tion is not dependent on frequency except at its upper frequency limits and it is 
normally operated at one supply voltage (+5.0 Vdc)„ 

Even though a data bus may have an operational speed of 10 MHz, many 
of its components may be operating at much slower rates. It would be reason- 
able to estimate from past experience that only 25 percent of the components 
need to operate at the maximum bus speed. Realistically the average speed 
would be 1/3 to 1/4 of the bus data speed. Therefore, components of a 10 MHz 
bus will be examined at 10 MHz and 2. 5 MHz and components of a 1 MHz bus 
will be examined at 1 MHz and 0.25 MHz. 

Studies have shown that a 1 MHz CMOS bus has approximately 1/8 the 
power consumption of a 1 MHz TTL low power bus. In addition, the 1 MHz 
CMOS bus has approximately l/25 the power consumption of a 10 MHz bus using 
both standard and low power TTL. These observations indicate that CMOS 
has the lower power consumption and is superior if operational speed is not the 
dominant factor. 
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TABLE C-l. CIRCUIT POWER DISSIPATION 


Type Circuit 

Dissipation Per Gate 
(mW) 

Typical Maximum 
Toggle Rate (MHz) 

TTL 



Low Power 

1.0 

3 

Standard 

10.0 

20 

High Speed 

23.0 

50 

CMOS 



@ 5 Vdc 

0.08 @ 0.25 MHz 

0. 38 @ 1 MHz 

1. 8 @ 5 MHz 

7 

@10 Vdc 

0. 4 @ 0.25 MHz 

1. 5 @ 1 MHz 
7. 8 @ 5 MHz 


@15 Vdc 

1.0 @ 0.25 MHz 
4. 3 @ 1 MHz 
35.0 @ 5 MHz 



C2. 0 TRADE STUDIES 


C2. 1 SUMMARY 

Based on the trade studies reported in the following subsections, the 
Spacelab data acquisition and distribution subsystem is defined as a hybrid, low 
rate, digital data bus in conjunction with a data exchange control unit. A 2 Mbs 
data bus, designed and fabricated with CMOS technology will be a low power, 
low cost system capable of handling all Spacelab subsystem data and over 80 
percent of the defined experiment payloads. The data exchange control unit, a 
20 input/20 output modular switching matrix, is used for distribution of audio, 
video, and high rate digital data requiring a rate higher than 2 Mbs. 
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The data bus consists of a computer interface unit, up to 32 digital inter- 
face units, and two-wire shielded twisted wire pairs operating at baseband under 
control of the processor subsystem. Each DIU may interface with up to 128 
analog inputs, discrete inputs, and discrete outputs. In addition, each DIU has 
the capability of providing up to eight serial digital data lines in and out and up 
to four analog outputs. 


C2. 2 SYSTEM ANALYSIS 
C 2. 2. 1 Data Requirements 

The DA&D subsystem must have the capability of servicing data from 
both Spacelab subsystems and experiment payloads. 


C2. 2. 1. 1 Subsystem Data Requirements 

Data from five subsystems ( stability and attitude control, data manage- 
ment, electrical power, environmental control and life support, and thermal 
control and structures) will be in the form of analog and discrete inputs and, 
in some cases, a serial digital word stream. Commands will be in the form 
of either discrete outs and/or serial digital words. Subsystem data require- 
ments are summarized in Table C-2 as derived from previous programs. The 
total consists of approximately 367 analog inputs, sampled at various rates 
from 0. 1 to 100 times per second, and 378 discrete inputs, assumed sampled 
once per second. (A requirement exists to sample the status of the discrete 
outputs. This would be accomplished by adding an additional number of discrete 
inputs to include discrete output monitoring. ) Three serial digital word chan- 
nels are also required to input approximately fourteen 16-bit words. 

The command structure requires approximately 192 discrete outputs 
and three channels of serial digital commands with up to 25 command words 
required on one channel. 


C2. 2. 1. 2 Experiment Data Requirements 

Data from the various experiment packages include both engineering and 
status data and scientific data. The data requirements for the individual experi- 
ment payloads are shown in Section C2. 5. These inputs were derived either 
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TABLE C-2. SPACELAB SUBSYSTEM DATA REQUIREMENTS SUMMARY 


Subsystem 

Measurements 

Controls 

Analog Sources 

Discretes 

Digital 

No. 

Word 

Length 

Discretes 

Digital 

No. 

Word 

Length 

0<M<0. 1 

1<M<1 

1<M<10 

10<M<100 

PACS 


67 

27 

1 

4 

5 a 

16 a 

11 

3 

16 a 

Data 

Management 


13 



65 

4 

16 a 

10 

25 

is a 

Electrical 

Power 

79 




47 

0 


58 

0 


Envi ronmental 
Control & 

Life Support 

32 

13 

77 


246 

0 


97 



0 


Thermal 
Control & 
Structure 

58 




16 

5 

16 a 

16 a 

14 a 

u a 

Total 

169 

93 

104 

1 

378 



192 




a. Estimate, 














































from a list of sensors contained in each experiment or as defined in the data 
requirements contained in Section C2, 5, Experiment Payload Definition. The 
breakdowns of analog and discrete data requirements for the Material Sciences 
and Life Sciences experiment packages were not available. Consequently, the 
data requirements for these experiments were derived only from Section C2. 5. 

A total of 45 experiment sources results in a maximum data rate of 51.4 
Mbs. However, Figure C-l illustrates the distribution of these experiment 
sources in percentages of the 45 total sources. It can be seen that a data acqui- 
sition and distribution system capable of handling 400 kbs would be able to 
service more than 82 percent of the experiment payloads. Other than the Earth 
Observations experiments, only Space Physics 12 through 14 at 2.4 Mbs and 
Astronomy A 5 at 7. 0 Mbs would require special handling. A data system capable 
of handling greater than 52 Mbs is required for Earth Observations. 

While the curve in Figure C-l shows a gradually increasing line from 
400 kbs to 50 Mbs, the curve is actually a series of step functions occurring at 
the individual experiment data rates. The smooth curve is presented only as a 
convenience. 


C2. 2. 2 Response Time Requirements 

The most stringent requirement imposed on the DA&D subsystem involves 
the sampling of discrete inputs during peak activities. To be capable of identify- 
ing all possible switch closures, each discrete must be sampled each 5 msec, or 
200 samples per second. From Table C-2, it can be seen that for Spacelab, the 
requirement is approximately 400 discretes. This requires 25 data words every 
sample or 5000 discrete data words every second. 

There is also a requirement for approximately 400 analog measurements 
to be sampled at no greater than 10 times per second. This corresponds to 200 
analog data words every 100 msec or 2000 analog data words per second. The 
total of 7000 data words represents a minimum of 140 000 bps for 20 bit words 
plus any overhead. However, it can be seen that any data acquisition and dis- 
tribution system designed to meet the experiment requirements would need only 
a slight increase in capability to meet response time requirements derived from 
Spacelab subsystem requirements. 
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1Q 2 
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EXPERIMENT DATA RATE IN bps 


10 ' 


10 * 


Figure C-l. Distribution of experiment sources. 


C2.3 CANDIDATE SYSTEM CONCEPT DEFINITIONS 

The choice of the Spacelab DA&D subsystem is based on the require- 
ments of growth potential and low initial and total cost. These requirements 
impose the following specifications on any data system: 

1. Provide a standard interface with experiments and subsystems. 

2. Reconfigurable without extensive and complex rewiring. 
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3. Simply expanded or reduced with a minimum of rewiring or scar 

weight. 

4. Provide a simple central interface point where support subsystems 
and experiments can be monitored or controlled. 

5. Involve little or no technology risk. 

Three candidate concepts have been considered for the Spacelab DA&D 
subsystem, a hardwire system, a combination low rate data bus and hardwire 
system, and a high rate data bus system. All three candidate concepts were 
configured to meet requirements defined in the preceding section. 


C2.3.1 Hardwire Data Acquisition and Distribution System 

A schematic of a hardwire data acquisition and distribution system for 
the Spacelab is shown in Figure C-2. It consists of the following hardware: 

1, Switch Selectors — To distribute commands to experiment sensor 
equipment and support subsystems. Each selector can handle up to 112 dis- 
crete outputs. At least one switch selector is required for each of the experi- 
ment and support Modules and one for the Pallet. The Earth Resources 
experiment payload requires an addition of seven switch selectors to handle the 
more than 800 DOs required for EO-1 through EO-6. 

2, Remote Multiplexers — To acquire and format analog and digital 
data for telemetry or recording for postflight analysis. The remote multiplexers 
can be programmed for different sampling rates and can handle up to 256 analog 
channels and up to ten 16-parallel- bit discrete channels. At least one remote 
multiplexer is required for each of the Experiment and Support Modules and 

one for the Pallet. Five remote multiplexers are required to handle the analog 
channels in the Earth Observation experiment payload. 

3, Main Multiplexer — Required in the Support Module to multiplex 
the inputs of up to six remote multiplexers. The main multiplexer performs 
the following functions: 

a. Scans the wavet rains of several (l to 6) remote multiplexers 
in a programmed sequence and combines these into a single wavetrain. 
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b. Encodes the wavetrain into a 16 bit digital form. 

c. Accepts data in digital form and programs it into selected time 
slots in the output serial format. 

d. Generates required word and frame sync. 

The outputs from both the remote and main multiplexers are routed either to the 
telemetry system or the recording system. These outputs are unavailable for 
use onboard. 

4. Junction Boxes — To provide standard wiring interfaces to analog 
and digital signals required for onboard use. This component is required in 
the Experiment Module and on the Pallet. One or more may be required in the 
Support Module. Signals required during flight from the experiment and support 
hardware must be provided a dedicated wire since no multiplexing capability is 
supplied. 


5. Distributor — To provide flexibility in routing signals to their 
intended destinations. The distributor provides some degree of versatility in 
changing channel assignments. An interconnection wire is installed in the dis- 
tributor for each signal. Changes are made by physically rearranging jumper 
wires within the distributor. 


C2. 3. 2 Hybrid Low Bate Data Bus and Hardwire Data Acquisition 
and Distribution System 

a 


The hybrid low rate data bus and hardwire system consists of the fol- 
lowing units, as shown in Figure C-3: 

1. A processor subsystem consisting of memory units, a CPU, and 
an input/output processor. The IOP interfaces directly with both the CPU, 
memory units, and CIU and houses the data bus executive software system for 
sending commands and transmitting data to and from the data bus. 

2. A computer interface unit which interprets requests from the IOP 
and translates them into commands for the acquisition and distribution of data. 
This unit contains a memory unit for temporary data storage and also houses a 
limited amount of checkout programs. This enables the CIU to operate the data 
bus independent of the IOP as required for data acquisition and distribution 
system diagnostics. The CIU provides format control for transfer of words 
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Figure C-3. Hybrid low rate data bus 



















onto and from the data bus. The CIU performs the required serial- to- parallel 
conversion for data input to the IOP and parallel-to- serial conversion on data 
output to the data bus. The required timing, synchronization, and control for 
proper two-wire data bus operation is also supplied by the CIU. 

3. Two-wire, full duplex digital interface units and compatible two- 
cable, shielded twisted wire pairs to accommodate the required data rate. 

The DFU provides a standard interface to the data bus for all subsystems 
requiring: 


a. Discrete inputs. 

b. Discrete outputs. 

c. Analog inputs. 

d. Analog outputs. 


e. Serial digital data channels either directly from a subsystem 
to the data bus (record in) or from the data bus directly to a subsystem 
(record out). 


4. A data exchange control unit to provide a switchable hardwire input/ 
output unit to accommodate high digital data rates and analog interfaces via 
dedicated cables with standard impedances and voltage levels. The DECU is a 
modular switching matrix to provide up to a 20 by 20 cross-point switching unit, 
This provides for multiple inputs and outputs, whereby any input can be connected 
to any of one or more outputs. Both analog and digital signals may be switched 
simultaneously. 


C2. 3.3 High Rate Data Bus 

The high rate data bus is made up of two data buses, a video or analog 
data distribution system and a high rate, FDM, coaxial cable, digital data 
acquisition and distribution system. 

The analog data distribution system is a standard TV cable distribution, 
75 ohm system ( Fig. C-4) . The transmitters, contained in the experiment 
packages, are connected to either the controls and display subsystem and/or 
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CHANNEL NO. 
2 

3 

4 

5 

6 

7 

8 
9 

10 


FREQUENCY (MHz) 
54 to 60 
60 to 66 
66 to 72 
76 to 82 
82 to 86 
174 to 180 
180 to 186 
186 to 192 
192 to 196 


Figure C-4. Analog data bus. 




the recorder subsystem through standard 75 ohm signal samplers. Multiple 
channel operation is possible, as required, by employing standard TV trans- 
mitters with vestigial sideband modulation and center frequencies in the standard 
VHF or UHF TV spectrum. 

The high rate digital data distribution system employs a 50 ohm, coaxial 
cable with modems to handle data rates greater than 70 Mbs. The high rate 
digital data bus system, shown in Figure C-5, is similar to the hybrid low rate 
data bus. The functions of the IOP, CIU, and DIU are identical to those of the 
low rate system. Only the data rates and, consequently, clock and circuit 
speeds are different. However, modems are necessary to handle the high data 
rates required to include all digital data on the bus. The analog bus and high 
rate digital data bus allow the elimination of the DECU utilized in the low rate 
data bus system. 


C2.4 TRADE STUDIES 

This section presents results of trade studies to select the Spacelab data 
acquisition and distribution system and the communication system. Six key issues 
were identified for the DA&D subsystem: 

1 . Power. 

2. Weight. 

3. Volume. 

4. Ease of expansion. 

5. Reconfigurability. 

6. Cost. 


C2.4.1 Command Housekeeping and Low Rate Data Hardwire Versus Data Bus 

Table C-3 contains the evaluation matrix for the hardwire versus low rate 
data bus trade study. 
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Figure C-5. High rate digital data bus. 







Evaluation 

Criteria 


Weighting 


Power 

5 

Weight 

5 

Volume 

5 

Ease of 


Expansion 

8 

R eeonfigur ability 

8 

Costs 

10 


Totals 


Hardwire 


Low Speed Data Bus 


Rating 

— 

Total 

Rating 

Total 

10 

50 

8 

40 

5 

25 

10 

50 

5 

25 

10 

50 

2 

16 

10 

80 

8 

64 

10 

80 

10 

100 

8 

80 


280 


380 
















Weight and volume estimates for comparative sized hardwire and data 
bus systems have been made both for the Shuttle 10 and for the Spacelab data 
acquisition and distribution subsystems 11 . In the Spacelab data, the similarities 
between the Spacelab and the ATM data systems are pointed out and the design 
reference model for the Spacelab is compared to the hardwire system of the 
ATM. Both studies indicate at least a 2 to 1 savings in weight and volume for 
the data bus system. 

One of the more important aspects of the DA&D system for the Space- 
lab is reconfigurability. As experiment packages are changed for different 
missions, it must be possible to reconfigure the data system at reasonable cost 
and within a reasonable amount of time. Assuming that no changes in size 
are required to reconfigure the data bus, it will still be necessary to replace 
used experiment sensors with new hardware. New equipment will have prepared 
cables for mating with a DIU. A new software package, verified and debugged, 
will be loaded into the processor system and reverified. 

To reconfigure the conventional system, again assuming no size changes 
are required, it is necessary bo exchange experiment sensor hardware, replace 
computer software, and reconfigure the distributor. Several options are 
available for reconfiguring the distributor. It could be rewired while still 
onboard, but the time required would be excessive. A replacement distributor, 
prepared in advance could be installed in place of the old one. The replace- 
ment distributor must be prepared for use by installing the proper set of 
interconnect wires. This could be done by using the flexible automated circuit 
tester (FACT) system comprising a computer and display device. A raw data 
list is generated and displayed to the operator showing where to locate each 
wire. If more automation is necessary, a computer-controlled automatic wire- 
wrap machine could perform the same function. Since reconfiguration of this 
concept requires more physical hardware replacement and modification, more 
time will be needed to verify the change and there will be more possibility to 
induce hardware and harness failures. 

The data bus concept described in Section C2. 3. 2 can be enlarged to 
as many as 32 DIUs on each pair of bus lines merely by installing the DIUs 
in the Spacelab, connecting them on the data bus, cabling the subsystems into 
the DIU T s standard interface, and loading or changing the appropriate soft- 
ware. 


10. IBM Final Report No. 70-M43-0008, Space Shuttle Phase B Digital Inter- 
face Technique Trade Study, August 28, 1970. 

11, Memo from Frank Emens. 
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Enlarging the conventional system after it is built is not at all easy. 

It appears that certain parts of the system cannot be expanded and must be 
sized for the maximum configuration when first installed. 

The number of digital outputs can be increased by adding more switch 
selectors and output wiring. The number of multiplex/recording inputs can be 
increased by increasing the number of remote multiplexers and adding more 
input wiring. The addition of more analog or discrete inputs for onboard use is 
not so straightforward. If the number of lines available in one junctions box is 
not adequate, it is necessary to add another box, another cable to the interface 
bulkhead, another penetration of the interface bulkhead, another cable from the 
interface bulkhead to the distributor, and a distributor with capacity to handle 
another cable. Modifications of this extent are probably not practical as a 
routine part of reconfiguration. Consequently, the system has to be built with 
all the internal cabling, distributors, and interface penetrations for the maximum 
sized mission. It may be practical to remove junction boxes and their cables 
when not needed but the rest of the system would become resident hardware and 
will fly whether or not it is used. 

The cost advantage of a data bus system is more or less intangible, as 
discussed previously, where ease of expansion, reconfigurability, and the time 
to accomplish these are concerned. The design costs of a data bus system have 
to be greater than those of a hardwire system because of the design complexity. 
Higher quality designers will be required, more initial checkout and design 
verification time will be required, and equipment costs will be higher. Soft- 
ware will be more complex and consequently more expensive. However, although 
there is no actual data for verification, it is felt that these costs will be more 
than compensated for through the Spacelab program life just through the savings 
of documentation control and lower costs for configuration management. 

For the purposes of this trade study, however, it was assumed that the 
hardwire data handling system would be slightly less expensive than the data 
bus design. Even with this assumption, the data bus concept appears to be the 
better system design to be used on Spacelab, as indicated in the trade study 
matrix. 


C2.4.2 High Rate Data Bus Versus Control Data Exchange Unit For Wideband 
Experiment Data 


In order to properly ascertain the advantages of a high rate data bus, 
the control word and message format should be defined as accurately as possible. 
This aUows an estimate of the overhead rates taxed on the data as a result of 
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data bus operation. Only then can a proper evaluation be made of a high rate 
data bus concept of data distribution versus a controlled, switchable, data 
exchange unit. 

The word formats, as defined for the design reference model DA&D 
system, are shown in Figure C-6, The message formats are as defined in 
Figure C-7. A command from the CIU to the DIU contains an A and a word- 
count word. Upon proper decoding of the A word, the DIU sends a sync word 
followed by the requested data and ends the transmission with an error status 
word. Blank words are on the command line when a message is not being trans- 
mitted. Blank words are also on the data line when write commands are sent 
to a DIU to fill the time slot from the receipt of the A word to the end of mes- 
sage. On receiving the end of message, and error status word is transmitted 
to the CIU. Blank words may also be interjected into the serial digital bit 
stream on the record in line to allow for differences in data speeds between the 
data bus and the interrogated subsystem. 

An estimate of the overhead rates were based on the Design Reference 
Model concept by a traffic flow analysis. The required time to obtain all sub- 
system data as defined in Section C2. 2. 1 was analyzed on a unit time basis. 

The details of those analyses are contained in Section C2. 5. Calculations were 
performed assuming data rates of 1, 2, and 5 Mbs. For these analyses, the 
data bus is occupied at all times with data transfers. For a 1 megabit data bus, 
the overhead rate was calculated to be 53,6 percent; for a 2 Mbs system, the 
calculated overhead rate is 55 percent. 

The time required to handle subsystem data is shown in Figure C-8 as 
a function of data bus speed, assuming that the subsystem data are transmitted 
over the bus an average of two times per message and contain approximately 
the same overhead structure in each transmission. (Two transmissions per 
data stream is an average based on data transfers from the subsystem DIU to 
the data bus processor and, after proper formatting, subsequent transfer to 
either the control and display subsystem, to the communication system, or to 
the recording subsystem. ) 

It can be seen that subsystem data represent a very light loading on any 
data bus operating at 1 megabit or greater. The allowable bus traffic time is 
850 msec. The time for subsystem data transfers is 50. 1 msec for a 1 mega- 
bit data bus and 25. 7 msec for a 2 megabit data bus, allowing 800 and 824 msec 
for experiment data transfers, respectively. If block transfers are assumed so 
that a 20 percent overhead loading is reasonable (see Section C2. 6), a 1 
megabit bus may handle up to 667 kbs of experiment data for unidirectional data 
transfers. If it is assumed that experiment data require two transfers, 
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1 1 0 
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ADDRESS 

OP CODE 

CHANNEL 
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I 1 

1 1 1 1 

lllli 
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a' word 
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OP CODE 

CHANNEL 

ADDRESS 


DIU TO DIU 

_LL 

1 1 1 1 

_M 1 1 

J.,.1. 1 1 1 
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RECORD OUT 




CHANNEL WORD 

COUNT 


WORD COUNT WORD 

1 1 0 

1 1 

COUNT 

1 1 1 1 1 
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P 


1 1 
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END OF MESSAGE 

1 
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LL 
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1 1 1 1 1 

COUNT 

IL 
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p 
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Figure C-6. Data bus word format. 
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the 1 Mbs data bus may handle up to approximately 333 kbs of experiment data. 
Figure C-9 shows the amount of experiment data capable of being transferred 
on the data bus as a function of data bus speed. It can be seen that a data bus 
rate of approximately 125 Mbs is required to handle all experiment require- 
ments as defined in Section 2. 1.2, and a 2 megabit bus can handle approximately 
690 kbs of data or better than SO percent of the defined experiment payloads. 


READ OIU 


CIU TO DIU 


A 


WORD COUNT 



SYNCH 

BLANK OR 




OIU TO CIU 

DATA 

D 1 

°N 

ERROR STATUS 


WRITE DIU CIU TO DIU J 

A 

WORD COUNT 

D t 

O n (EOMI 








DIU TO CIU 


SYNCH 

■LANK 

BLANK 

BLANK 

ERHOR STATUS 


Figure C-7. Data bus message formats. 



Figure C-8. Subsystem data transfer time as a function of data bus speed. 
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Figure C-9. Experiment data accommodated on a data bus 
as a function of data bus speed. 

C2.4. 2. 1 Analog Data Acquisition and Distribution System 

The major difference between the high rate data bus video or analog data 
transmission system and the DECU is in the manner of handling several channels 
simultaneously. The high rate analog data bus operates in a multiple channel 
mode as defined in Section C2.3.3. Standard TV transmitters with vestigial side- 
band modulators and standard TV carrier frequencies can be used. The DECU 
allows the transfer of analog and video data at baseband frequenceis by essentially 
providing a switchable hardwire connection from the source to the destination 
subsystem. These two methods seem to be equally advantageous with respect 
to technical capabilities and total cost. The cost of the DECU at something less 
than $ 50 per cross point, and associated logic plus line drivers and terminations 
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is offset by the cost of the TV modulators. The extra cost of the TV transmit- 
ters to drive the analog bus is modified by the extra capability of having several 
video channels available at a receiver merely by selecting a tuner channel. 
Standard commercial TV receivers could be used with the analog bus, whereas 
digital logic has to be generated in the data bus processor, on receipt of a 
command, to switch input/output channels of the DECU. Technologically, both 
distribution systems seem to adequately meet requirements at moderate cost, 
so other reasons should be found for selecting one concept over the other. 


C2.4. 2. 2 High Hate Digital Data Acquisition and Distribution System 

The high rate digital data acquisition and distribution system versus the 
DECU concept trade study matrix is shown in Table C-4. The DECU concept 
appears to be the better design concept to be used on Spacelab. 

TABLE C-4. HIGH RATE DIGITAL DATA BUS 
VERSUS DATA EXCHANGE CONTROL UNIT 


Evaluation 

Criteria 

Weighting 

High Rate Digital 
Data Bus 

DECU 

Rating 

Total 

Rating 

Total 

Power 

5 

1 

5 

10 

50 

Weight 

5 

10 

50 

8 

40 

Volume 

5 

10 

50 

8 

40 

Ease of 






Expansion 

8 

10 

80 

8 

64 

Reconfigurability 

8 

10 

80 

9 

90 

Costs 

10 

1 

10 

10 

100 

Totals 



275 


384 
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The margin over the hardwire system is approximately the same as in 
the low rate data bus concept. The DECU concept provides switchable hardwire 
distribution of analog and high rate digital data but provides for data bus distri- 
bution of low rate digital data. Consequently, the weight and volume penalities 
for this concept are not very severe. In fact, more than 80 percent of the 
experiment payloads can be handled with a low rate digital data bus operating 
at speeds of 1 or 2 Mbs. 

Relative cost figures are derived from two sources , Table C- 5 and 
design experience. Table C-5 shows high speed digital circuitry (MECL HI) 
to be at least 12 times as costly as low speed CMOS. In addition, the design 
and checkout of a 100 Mbs data bus would be much more complex than that of a 
1 Mbs data bus and design and checkout costs will override any hardwire dif- 
ferential costs. Consequently, the technological risk involved in a 100 Mbs data 
bus design is an overriding factor in any concept selection. This fact is not 
entered in the trade study matrix but adds significantly to the engineering reasons 
for selecting a DECU for high rate data handling. 

Once the decision is made to special handle all but low rate digital data, 
the term low rate must be defined. As seen from Table C-5, today T s circuit 
technology seems to indicate a rate of less than 5 Mbs. CMOS technology is 
preferred for LSI circuits because of low cost and extremely low power. This 
would limit operation to around 1 or 2 Mbs for ease of design. Standard TTL 
circuits have been in use for some time and MSI designs with this technology will 
be less costly in terms of design and checkout time than any other technology. 
Standard TTL circuit power and hardware costs will be slightly higher than for 
CMOS. 


In addition to circuit technology, coupling adds a slight factor in favor of 
low data rates. Figure C-10 is a typical curve illustrating one ferrite core 
manufacturer’s available core material specifications. Below 10 6 Hz, ample 
materials are available for use as a coupling transformer core; permeability 
is no problem. Above 10 6 Hz the availability becomes a problem and the initial 
permeability is orders of magnitude below those materials used at lower fre- 
quencies. This is indicative of the many design problems encountered at high 
frequencies. Since a 2 Mbs data bus will handle all subsystem data and over 
80 percent of the defined experiment payloads, this approximate data rate 
seems a logical choice. 

C2. 5 SPACELAB EXPERIMENT DATA REQUIREMENTS SUMMARY 

This section contains the data requirements for the individual experi- 
ment payloads. These requirements are presented in tabular form in Tables 
C-6 and C-7. The source for these data is MSFC Sortie Lab Task Report 4.1. 3. 
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TABLE C-5. CIRCUIT TECHNOLOGY 


Logic 

Type 

Typical 
Propagation 
Speed (nsec) 

Maximum 
Toggle 
Speed (MHz) 

Power 

Per 

Gate (mW) 

Corresponding 
Data Bus 
Rate 3 (Mbs) 

Cost 

Per Quad 
Gate ( $ ) 

CMOS 

60 

2. 5 

1-0 

750 

1.00 

Low Speed 
Low Power 
TTL 

35 

3.0 

1 

1 

2. 80 

Low Power 

Schottky 

Devices 

10 

25.0 

4 

4 

5.10 

Medium 

Speed 

TTL 

12 

25.0 

10 

3 

2.33 

High 

Speed 

TTL 

(3000) 

6 

43.0 

22 

8 

2.91 

Very 
High 
Speed 
TTL .(74 5) 

3 

110.0 

20 

15 

3.50 

ECL 

(MECL II) 

4 

90.0 

20 

10 

2. 23 

ECL 
(MECL 
10 000) 

2 

160.0 

25 

20 

3.75 

ECL 

(MECL III) 

1 

300.0 

60 

40 

11.25 


a. Judgement on practical maximum serial digital rates without undue circuit complexity. 
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TABLE C-6 (Continued) 
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TABLE C-6 (Concluded) 


Experiment 

L 

Measurements 0 


Remarks 

Analog Sources (Sample Rate/Sec) c 


1 Digital Words 


Number 

Word 

Length 

Controls 

0.1 <M < 1 

1 < M < 10 

10 <M < 100 

100 <M < 1000 

Events 

Earth Observations 
(Concluded) 










EO-7 

(TBD) 

EO-8 

(TBD) 









EO-9 

(TBD) 









Technology 


19 


1 @3K 




30 


T-l 

T-2 


19 


1 @3K 




30 


T-3 

356 



TV 

62 



30 


T-4 

300 

40 


TV 

4 



15 


T .5, T-6 

300 | 

54 


TV 

108 



25 


T-7 

42 


15 

TV 

25 



5 


T-8 

370 

40 

6 

TV 




10 


T-9 

SO 

20 

15 

TV 




100 


Comm-Nav 

20 

10 


10 Mbs 

16 

2 

8 

20 

Max data rate for one 
experiment 

Planetary 

20 

8 


1 (12.5) 
1 (25) 

1 (31) 

1 (150) 

24 



24 


P-1 


a. Each is Housekeeping Experiment. 

b. M denotes rate. 

c. The number within the parentheses is the sample rate. 

d. The top number indicates the number of measurements within litis range; the bottom number indicates measurements beyond this range 




TABLE C-7. SPACELAB EXPERIMENT DATA REQUIREMENTS SUMMARY 
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TABLE 07. (Continued) 
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TABLE C-7. (Continued) 


Communieation/Navigation 


C/N-l 


Data Acquisition Requirements 

Data 

Data 

Data 

Type 

Rate 

Category 

Digital 

84. 7 Kbs 

* 

TV (2 chn) 

10 MHz 

S 

Digital 

350 bps 

E 

TV (2 chn) 

5. 8 MHz 

S 

Digital 

160 bps 

E 

Digital 

760 bps 

E 

TV (2 chn) 

5. 8 MHz 

S 

Digital 

5. 78 bps 

E 

TV (1 chn) 

2. 9 MHz 

s 1 

Digital 

5. 0 kbs 

E 

TV (1 chn) 

2.9 MHz 

S 

Digital 

8 kbs 

E 

TV ( 1 chn) 

2.9 MHz 

S 

Digital 

3. 8 kbs 

E 

TV (1 chn) 

2.9 MHz 

S 


Digital 

Voice 

Analog 


100 kbs 
Max 


10 Hz 
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TABLE C-7. (Concluded) 



Data Acquisition Requirements 


Data 

mgm 

Data 

a 

Category 

Payload 

Type 

HaH 

Planetary 




P-1 




lm Planet 
Telescope 




UV Spectrometer 

Digital 

100 bps 

E 

IR Interferometer 

Digital 

250 bps 

E 

Photopolarimeter 

Digital 

200 bps 

E 

TV 

Digital 

3 . 3 kbs 

S 

IR Telescope 

Digital 

100 kbs 

S 

mm/Sub-mm Radio 
Telescope 

Digital 

3 . 5 kbs 

S 

Material Sciences 




MS-1 through MS-4 

Digital 

30 kbs 

E 


TV (1 chn) 

3.3 MHz 

S 

Life Sciences 

Digital 

62. 5 kbs 

E 


Voice 


E 


TV 

3.3 MHz 

S 


a. E — Engineering and status data; S — Scientific data; * — Combined 
data stream of engineering and scientific data. 
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C2.6 SPACE LAB DATA BUS TRAFFIC CALCULATIONS BASED ON SPACE- 
LAB SUBSYSTEM MEASUREMENT AND CONTROL LIST SUMMARY 

The following assumptions and DIU capabilities and requirements were 
used to generate the information that is summarized in Figure C-8 and Table 

C-8. 


1. Assumptions: 

a. Each transmission to a DIU may be delayed a full word time. 

b. Each transmission to a DIU consists of an A word and a word 

count field. 

c. Each word contains 16 bits of information, 3 bits of prefix 

plus parity. 

d. Each transmission to the CIU consists of a sync word, no 
more than one blank word (on READ RI) , and an error status word. 

e. All data updates involve total DIs, DOs, or AIs one one DIU. 

f. System delays consist of 2 ^sec for logic, 1 psec for circuit 
delays, 1 Msec for propagation delay. 

g. All subsystem data involved in two data bus transmissions, 
one from DIU to CIU, and either one from CIU to recorder or one from CIU 
to C&D. 


2. Subsystem DIU Assignment: 

a. Stability and Attitude Control, Unit #1 


AI 

67 

1 s/s 


27 

10 s/s 


1 

100 s/s 

DI 12 

15 

1 s/s 

DO 

11 

1 s/s 

RO 13 

3 words 

1. 1 s/s 

RI 

5 words 

1 s/s 


12. DIs include measurement of DOs. 

13. RO assumed 1.0 sec between updates. Fourteen words assumed for 
unit # 7. 
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b. Data Management, Unit #2 


AI 

13 

1 s/s 

DI 

75 

1 s/s 

DO 

10 

1 s/s 

RO 

25 words 

1 s/s 

RI 

4 words 

1 s/s 

Electrical Power System, Unit #3 

AI 

79 

0.1 s/s 

DI 

105 

1 s/s 

DO 

58 

1 s/s 


d. Environmental Control and Life Support, Units #4, 5, and 6 


#4 

AI 

32 

0. 1 s/s 

#5 


13 

1 s/s 

#6 

112,1 


77 

10 s/s 

112, 
128 J 
112,| 

| DI 

343 

1 s/s 

o, ol 

> DO 

97 

1 s/s 

Thermal Control and Structure, Unit #7 


AI 

58 

0. 1 s/s 


DI 

32 

1 s/s 


DO 

16 

1 s/s 


RO 

14 words 

1 s/s 


RI 

5 words 

1 s/s 
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TABLE 08. TRAFFIC FLOW SUMMARY FOR 1 AND 2 Mbs DATA BUS 


DIU 

Number 

Time for Transmission 
at 1 Mbs, nsec 

Time for Transmission 
at 2 Mbs, Msec 

CIU to DIU 

1 

7 095 

3 605 

2 

825 

415 

3 

208. 1 

105. 1 

4 

268. 1 

135. 1 

5 

122 

62 

6 

671 

341 

7 

550. 1 

277. 1 

Subtotal 

9 739.3 

4 940. 1 

DIU to CIU 

1 

6 052 

3 252 

2 

352 

182 

3 

224.4 

114.4 

4 

176.4 

90.4 

5 

288 

148 

6 

8 004 

4 024 

7 

226.4 

117.4 

Subtotal 

15 323.2 

7 928.2 

Total 

25 062. 5 

12 868.3 
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The overhead calculations assume the actual number of total data bits 
shown below and utilize the previously calculated interrogation and reply times 
for (he respective data bus rates. This information is summarized in Table 
C-9. 


Total Data Bits: 

DIU 1 

3 594 

DIU 2 

653 

DIU 3 

226.2 

DIU 4 

234.6 

DIU 5 

216 

DIU 6 

6 279 

DIU 7 

398.4 


11 601.2 Actual Data 


TABLE C-9. OVERHEAD ANALYSIS FOR 1 AND 2 Mbs DATA BUS 



Overhead for 1 Mbs 
Data Bus 

Overhead for 2 Mbs 
Data Bus 

Total Bits 

25 062 (equivalent) 

25 736.6 

Overhead 

13 461 

14 135.4 

Overhead 

Rate 

53. 6% 

55.0% 

Efficiency 

46.4% 

45.0% 
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For the special case of block transfers of experiment data, the follow- 
ing data bus parameters are assumed for 1 Mbs data rate: 

Subsystem Data 25 msec 

Bus Utilization 85 % 

The total allowable time for experiment data on the bus is 825 msec (850 - 25) . 
Total experiment data rate = 0. 825 x 10 6 x 0. 80 (av) assuming block transfers 
greater than 256 sixteen-bit words. Total allowable experiment data rate is 
660 kbs one way. If the data have to be transmitted on the bus twice (as to the 
data acquisition system processor and, thence, to the control and display 
system) , the allowable experiment data rate is 330 kbs, assuming block trans- 
fers in both directions. 

For the following data bus parameters, the allowable time for experi- 
ment data on the bus is 837. 1 msec ( 850 - 12. 9) : 

Total Data Rate 2 Mbs 

Subsystem Data 12. 9 msec 

Bus Utilization 85 % 

If an overhead burden is assigned equivalent to subsystem data loading, 
the total experiment data rate (average EDR) = (0.84) (2x 10 G ) (0.464)*= 

780 kbs unidirectional data transfers. However, if block transfers are effected 
such that the overhead rate approaches the minimum (20 percent) , then the 
total average EDR = (0. 84) (2 x 10 G ) (0. 80) = 1.34 Mbs maximum for undirec- 
tional block transfers. If the data are required on the bus for two transmis- 
sions, the total experiment data rate allowed on the bus is 670 kbs, assuming 
block transfers in both directions. 

Since there are four overhead bits per word, 20 percent is the best 
loading to be achieved. To calculate the block length required to reduce over- 
head to less than 25 percent, consider the following for a 2 Mbs bus: 

CIU to DIU 


RO, 1 word delay 10 

A 10 

B 10 

Propagation 1 


31 psec 
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DIU to CIU 


RI delays 4 //sec 

Error Status Word 10 Msec 

X Digital Words 10 X 

10 X + 14 Msec 

The required time for transmission of data is N (10 X + 45) Msec, as shown in 
Table C-10 where the column headings are defined as follows: 

N Number of transmissions in 1 sec 

T Time per transmission 

X Digital data words per transmission 

Overhead Percentage of total data 

Rate 

It can be seen from this table that for any block transmission over 300 words in 
length, overhead rates approach 20 percent, A block transfer of 256 words would 
result in an overhead rate of approximately 21 percent, 

TABLE C-10. BLOCK TRANSFER ANALYSIS FOR 1 AND 2 Mbs CASES 


N 

T 

X 

Overhead Rate 
(%) 

1 

835 msec 

83 495 

20 

10 

83. 5 msec 



20 

41. 75 msec 



50 

16. 7 msec 

1 665 

20.2 

100 

8. 35 msec 

830 

20.5 

278 (3 msec) 

3. 00 msec 

295 

21.2 

320 

2, 60 msec 

256 

21.4 

500 

1. 67 msec 

162 

22.2 

1000 

835 p sec 

79 

24.4 

5000 

167 Msec 

12 

41.6 
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The basic assumptions and DIU capabilities used in the traffic flow 
analysis for the 1 and 2 Mbs data rate cases were used for the 5 Mbs case. 
The results are summarized in Table C-ll. 


TABLE C-ll. TRAFFIC FLOW SUMMARY FOR 5 Mbs SYSTEM 


DIU No. 

CIU to DIU 
(psec) 

DIU to CIU 
(jusec) 

Total Time 
(/^sec) 

1 

1780 

1572 

3352 

2 

189 

80 

269 

3 

51.7 

48.4 

100.1 

4 

63,7 

38.8 

102.5 

5 

34 

64 

98 

6 

187 

1636 

1823 

7 

129.7 

52 

181.7 

Total 



5926 


Actual Data 

11 601 bits 


Total Data ( Equivalent) 29 631. 5 bits 



Overhead - 

18 030.5 bits 



Overhead Rate 

60.5 % 



Efficiency 

39. 5 % 
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For 5 Mbs data rate, the following transmission times are required for 
block transfers of experiment data: 

RO Command Time 1 s/s 17 Msec 

Reply RI Time 1 s/s (4X + 8) Msec 

The total message transmission time is N (4X + 25) Msec. Total transmission 
time is 844 msec ( 850 - 6) . 

The 5 Mbs block transfer analysis is given in Table C-12 where it can 
be seen that for any block transfers of more than 500 data words, overhead rates 
approach 20 percent. Assuming that block transfers greater than 512 words 
are used, the allowable experiment data rate is (0. 844) (5 x 10 6 ) (0. 78) or 
3,39 Mbs for a unidirectional data transfer. Assuming the same block transfers, 
an experiment data rate of approximately 1.7 Mbs would result in an 85 per- 
cent data bus utilization. 

TABLE C-12. BLOCK TRANSFER ANALYSIS FOR 5 Mbs CASE 


N 

T 

X 

Overhead Rate 
(%) 

1 

844 msec 

210 994 

20 

10 

84. 4 msec 

21 094 

20 

100 

8.44 msec 

2 104 

20.2 

500 

1688 Msec 

416 

21.2 

805 

1049 M sec 

256 

21.8 

1000 

844 Msec 

205 

22.2 

5000 

169 Msec 

38 

27 
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C3.0 REMOTE VERSUS CENTRALIZED LIMIT CHECKING FOR SPACE LAB 
DATA ACQUISITION AND DISTRIBUTION S YST EM 


The study of remote versus centralized limit checking for Spacelab 
involves the analyses of three different concepts: 

1. Remote limit checking in the data interface unit. 

2. Local or central limit checking in the computer interface unit. 

3. Central limit checking in the SUMC processor. 

Limit checking in the input/output processor was considered briefly but was 
dismissed as viable concept because of the multitude of required functions and 
the heavy utilization of the IOP just to maintain orderly control of all periph- 
erals. 


The stucty involved investigation of the following areas: 

1. Power dissipation and hardware requirements for all three 
concepts. 

2. Differences in data bus traffic among the three concepts. 

3. Differences in IOP/CIU channel utilizations. 

4. Differences in processor utilizations. 

From preliminary analyses, it appears that the most economical and 
efficient method of performing limit checking is in the DIU, i. e. , remote 
limit checking. 

C3. 1 CONCEPT DEFINITION AND REQUIREMENTS ANALYSIS 

Three alternate concepts of limit checking have been analyzed, one 
involving remote limit checking and two utilizing centralized limit checking. 
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C3.1.1 Remote Limit Checking in the DIU 

The basic requirement for limit checking capability involves 128 analog 
and 128 discrete inputs. Additional memory in each DIU is required for limit 
storage. Some additional logic is also required to make two comparisons 
(worst case) of the analog values with the upper and lower limit values and to 
compare the discrete inputs with their limits. (Discretes would be compared 
with only one value to ascertain whether and when a status change occurred. ) 

The additional required memory for limit checking is 2176 bits for a 
total memory size of 3328 bits as shown in Table C-13. The DIU memory size 
without limit checking is 1152 bits and includes memory for 128 eight-bit analog 
inputs and 128 single-bit discrete inputs. If TTL logic is used, the additional 
power required of each DIU is 24.4 watts, as shown in Table C-14. Assuming 
power requirements are derived from memory requirements, DIU power 
requirements without limit checking would be approximately 13 watts based on 
18 memory chips to accommodate 1152 bits. Twenty-four watts of additional 
power would probably require heavy duty, regulated power supplies in addition 
to stringent design to allow for adequate power dissipation. However, the DIU 
logic can be designed using CMOS circuits. A CMOS static memory chip of the 
Fairchild MOS 3532 type requires 230 mW maximum for 512 bits. Limit check- 
ing thus requires a maximum of 5 chips for a total additional power require- 
ment of 1.2 watts per DIU, or approximately 40 additional watts for a fully 
loaded data bus operating with 32 DIUs. The Spacelab will require approximately 
21 DIUs based on the measurement list contained in Section Al. Consequently, 
remote limit checking in the Spacelab with CMOS technology will require 
approximately 25 watts of additional power. 

C3.1.2 Central Limit Checking in the CIU 

Limit checking in the CIU may be performed by two different methods, 
storing the limits for all DIUs in the CIU and storing only the limits for one 
DIU at a time in the CIU and transferring those limits associated with the polled 
DIU from the processor as and when required. 

Storing all DIU limits in the CIU requires the same amount of hardware 
and additional power as required for remote limit checking. Consequently, no 
hardware, design, or power saving is accomplished with this concept. In 
addition, data bus traffic increases significantly. The curves of Figure C-ll 
illustrate the data bus utilization for varying sample rates. All calculations 
assume no out-of- limit conditions, the normal operative mode. It can be seen 
that a sampling rate for both analogs and discretes of 20 times per second 
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TABLE C-13. MEMORY SIZE CALCULATION 



Size (bits) 

For Limit Check Only 


Analog Upper Limits (128 words x 8 bits) 

1024 (max) 

Analog Lower Limits 

1024 (max) 

Discrete Limits (128 discrete x 1 bit) 

128 

Subtotal 

2176 (max) 

Data Value Storage 


Analog Values (128 words x 8 bits) 

1024 

Discrete Values (128 words x 1 bit) 

128 

Subtotal 

1152 

Total 

3328 


TABLE C- 14. POWER REQUIREMENTS FOR TTL 
LIMIT CHECKING MEMORY 


Item 

No. Chips 
Required 

Power/ Element 
(mW) 

Total Power 

Memory 
(INTEL 3101 
64 bit) 

34 

700 

23. 8 W 

Comparator 
(INTEL 54L85) 

2 

20 

40.0 mW 

Shift Register 
(SN 5494) 

8 

20 

160.0 mW 

Logic Circuits 
(SN 5400) 

72 

5 

370. 0 mW 

Total 

116 


24.370 W 
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(corresponding to 50 msec per sample) represents a data bus utilization of 60 
percent. While this is possible, it leaves no capability for servicing experi- 
ments, Further, the greatest sampling rate of both analogs and discretes which 
can be serviced by a 2 Mbs data bus with central limit checking is 30 samples 
per second. As shown by related studies, SO percent of the experiment payloads 
can be accommodated by a 2 Mbs data bus, but only when the subsystem house- 
keeping data represent approximately 50 msec or less of data bus traffic. This 
represents a data bus utilization of 50/1000 or 5 percent. From Figure C-ll, 
it can be seen that any sampling rate greater than once per second for analogs 
and five times per second for discretes raises the data bus utilization over 5 
percent. Further, it can be seen that the required sampling rate of 200 times 
per second for discretes requires an analog sampling rate less than 10 times 
per second in order for the data bus to handle just subsystem analog and 
discrete data. Sampling of discretes at 200 times per second and analogs at 
once per second represents a 75 percent data bus utilization. It must be noted 
that the above utilizations do not account for any traffic from discrete output 
updates. This traffic would be in addition to the analog and discrete inputs and 
raises the total bus utilization higher than the curves shown in Figure C-ll. 


MOTE: 32 MU* FULLY LOADED. DATA BUS BATE OF 2 mb* 



SAMPLING RATE IN SAMPLES/SEC 


Figure C-ll. Data bus utilization for CIU limit checking 
at varying DI sample rates. 
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C3. 1. 3 Central Limit Checks in the SUMC 


Limit checking in the SUMC processor requires the following actions: 

1. Transfer of data from DIU to CIU. 

2. Transfer of data from CIU to IOP interleaved with other preipheral 
data streams. 

3. Transfer of data from the IOP to a memory location. 

4. Storage to storage comparison. 

5. Execution of a branch on condition for each limit check instruction. 
(For purposes of comparison, no out- of- limit conditions are assumed. ) 

The transfer of data from the DIUs to the CIU represents the same data 
bus traffic as defined in Figure C-ll. The CIU to IOP data transfer requires 
approximately 15 /nsec per DIU based on a transfer rate of 10 n sec plus 1 ^isec 
per 16- bit word. Since the DIU to CIU transfer requires approximately 900 
jusec per DIU, the IOP/CIU rate is such that IOP loading is neither appreciable 
nor the limiting factor. 

The SUMC has a cycle time of 1. 2 psec. Four cycle times, or approxi- 
mately 4. 8 jusec, are required for an add operation. 

Seven equivalent add instructions must be executed to limit check each 
analog value for a time of 33. 6 nsec per sample. Assuming that no out- of- limit 
conditions exist, the processor time required to service one DIU containing 128 
analog data points is 4. 3 msec. For a fully loaded data bus, 138 msec are 
required to limit check all analog data samples. This represents an approxi- 
mate processor utilization of 15 percent when all analogs are sampled once per 
second and 10 percent is allowed for overhead. 

Three equivalent add instructions are required to execute change status 
testing on eight discretes. Thus, eight discretes may be checked in 14.4 psec. 
Consequently, a fully loaded DIU can be checked for discrete changes in 230.4 
jiisec. If all analogs and discretes in a fully loaded DIU are checked, approxi- 
mately 5 msec are required, allowing 10 percent for overhead. Since response 
time requirements differ for analogs and discretes, the means of evaluating 
processor utilization for limit checks should allow discretes to be sampled 
independently and at different rates than analogs. Knowledge of discrete 
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changes are required within 10 msec (a minimum sample rate of 100 times per 
second) with a 5 msec response time highly desirable and a 2 msec response 
time being considered. Figure C-12 displays the SUMC processor utilization 
as a function of discrete signal sampling rate for a fully loaded, 32 DIU data 
bus system. Figure C-13 illustrates the processor utilization for analog limit 
checking, for the same configuration, and Figure C-14 shows the composite 
processor utilization rate for limit checking analogs 20 times per second 
(every 50 msec) and discretes 100 times per second (every 10 msec) for 
different utilizations of a 32 DIU data bus. 

It can readily be seen, that while limit checking discretes in the SUMC 
is possible, sampling all discretes of a fully loaded data bus at 100 samples 
per second would require a dedicated processor. Further, it can be seen that 
limit checking analogs in the SUMC is not possible for any sampling rates 
greater than seven samples per second. In addition, performing limit check- 
ing on both analogs and discretes at the required sample rates is just not 
feasible for any data bus loading greater than 5 to 10 percent. 


C3.2 CONCLUSIONS AND RECOMMENDATIONS 

The performance of limit checking in the SUMC processor requires a 
dedicated processor just to meet discrete signal limit check sampling rate 
requirements. 

Performing limit checking in the CIU requires as much hardware and 
power as performing the function in the DIUs. In addition, locating the limit 
checking capability in the CIU requires increased complexity in an already 
complicated design. This functional allocation also maximizes the results of 
a single point failure. Should the limit checking function fail in the CIU, all 
limit checking is lost. If limit checking fails in the DIU, only one set of data 
points loses the limit checking capability. Further complexity is added by the 
significant increase in data bus traffic to perform centralized limit checking. 

Allocation of the limit checking function to either the CIU or the SUMC 
processor requires an additional data bus and associated DIUs to service sub- 
systems. Performance of limit checking of discretes in the SUMC requires 
a dedicated 30 OK to 400K operations per second machine. In view of the slight 
increase in power requirements and DIU design complexity for remote limit 
checking, it is strongly recommended that limit checking of Spacelab sub- 
system data be performed remotely in the DIU. 
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Figure .C-14. Processor utilization for composite limit checking, 



C4 .o DATA ACQUISITION AND DISTRIBUTION SYSTEM SELECTION 
C4. 1 INTRODUCTION AND SCOPE 

The primary function of a data acquisition and distribution system is the 
transfer of commands/data at the required rates between the data management 
subsystem and other subsystems and experiments. This section documents the 
study results and rationale used in selecting a data bus concept for the Spacelab 
data acquisition and distribution system. 


C4.2 RECENT TRENDS 

The recent trend followed by both NASA and the Air Force is to use data 
bus subsystems for the data acquisition and distribution function. The Air Force 
is using a data bus in the B-l bomber and in the F-15 fighter. Present NASA 
plans call for use of a data bus in the Space Shuttle, and the data bus has been 
proposed for use in the Space Tug, RAM, and the Space Station. 

The types of data bus concepts vary with application. The B-l bomber 
uses a 1 MHz data bus with remote interface units. The presently proposed 
concept for the Space Shuttle is to use multiple data buses with each bus being 
a 1 Mbs, two-line system with the capability of interfacing with up to 31 
multiplexer-demultiplexers (MDMs) which, in turn, interface with the 
subsystem components. A 10 MHz bus was proposed for the Space Station. 

C4.3 DATA BUS VERSUS CONVENTIONAL DISTRIBUTION SYSTEMS 
C4.3.1 Data Bus Concept Description 

The data bus concept proposed for Spacelab is illustrated in Figure C-15 
and would have the following characteristics: 

1. Speed: 1 megabit (can be increased to 2 megabits if data levels 
require it) . 

2. Control: Under central control closely related to computer soft- 
ware. 


3. Transmission Medium: Two twisted shielded pairs, one for data 
transmission from the CIU to the DIUs and one for transmission from the DIUs 
back to the CIU. 
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Figure C-15. Data bus approach 
















4. Number of Remote Terminals: Approximately 10. The concept 
could accommodate 4 to 5 times as many DIUs but 10 seems a good estimate 
nnt-. i1 better information on data requirements is available. Address word size 
will probably be set at 5 bits, allowing up to 32 DIUs. 

5. Capability of Remote Terminals: Selection of a size for the DIU 
must be the subject of trade studies requiring more data than is now available. 
The following I/O capability is assumed for comparison purposes: 64 discrete 
inputs, 64 discrete outputs, 64 analog inputs, and 16 analog outputs. 

6. Error/Fault Protection: Will use error protection concept, at 
least as effective as combined horizontal and vertical parity. 

For purposes of comparison, a minimum size data bus system using 
only four DIUs is shown. This could be expanded to 10 by merely tapping the 
additional DIUs into the bus lines and wiring the subsystem into the DIU's I/O 
interface. 


C4.3. 2 Conventional Distribution System 

A conventional (Saturn launch vehicle type) data acquisition and distri- 
bution system would require the following items of hardware: 

1. Switch Selectors: At least one each for Experiment Module, Support 
Module, and Pallet. 

2. Multiplexers: One or more in Experiment Module, Support Module, 
and Pallet. 


3. Distributor: Minimum of 1 in the Support Module. 

The switch selectors are necessary to distribute commands to the 
experiment sensor equipment and to the support subsystems. One selector 
can handle 112 DOs. 

The multiplexers are used to acquire and format analog and digital data 
for telemetry or recording for postflight analysis. Their outputs cannot be 
used for onboard data requirements. 
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The junction boxes are used to provide standard wiring interfaces to 
analog and digital signal outputs that are required during flight from the experi- 
ment and support hardware. No multiplexing capability is provided for these 
signals so a dedicated wire must be provided for each one. 

The distributor is required to allow flexibility in routing signals origi- 
nating in subsystems to their intended destinations. This is accomplished by 
installing an interconnection wire in the distributor for each signal. 

For purposes of comparison, a minimum size conventional system 
equivalent to the four-DIU data bus is assumed. This system could be 
expanded by adding more switch selectors, by adding more (or larger) junction 
boxes and increasing the number of size of interconnecting cable bundles, and 
by increasing the number of remote multiplexers. 


C4.3. 3 Comparison of Approaches 

The two approaches, data bus and conventional, are compared in five 
areas. These areas are weight, ease of reconfiguration, growth, cost, and 
power. It should be noted that for the purposes of this study, the high rate 
experiment data will be handled using a conventional approach and will be 
excluded from this comparison. 


C4.3.3.1 Weight 

An indication of the weight of a conventional system may be obtained by 
considering an equivalent system. The Skylab Apollo Telescope Mount is 
considered to be equivalent to the Spacelab with an astronomy experiment using 
the standard experiment point base. The ATM distribution system, including 
signal cables and distributors, is approximately 816.48kg (1800 lb). Other 
studies have shown that a 40 to 50 percent reduction in weight can be achieved 
by using a data bus system. 

A Shuttle study was conducted to compare an integrated data manage- 
ment system to a discrete wire approach. 14 It is emphasized in this report 
that these particular results are applicable only to the Shuttle; however, the 
relative merits of the two approaches should be as applicable to Spacelab as 
to Shuttle. 


14. IBM Final Report No. 70-M43-0008, Space Shuttle Phase B Digital Inter- 
face Technique Trade Study, August 28, 1970. 
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In this study, a total of 4729 measurements are estimated; 1613 of these 
are analogs. It was assumed that the switch selector/IO device is the center of 
gravity of the electronic measurement density and is located approximately 
24. 384 m (80 ft) from the vehicle nose. From these, a total wire run length 
of 53 035. 2 m ( 174 000 linear feet) is calculated for measurements. Assuming 
that a twisted and shielded pair wire is used for EMI protection for low (less 
than 5 volts) signals and assuming an estimate of 22.31 kg/10 3 m (15 lb/10 3 ft) 
wire weight, the total wire weight for the measurements is 53.035 x 4. 572 = 

1183.6 kg [(174 x 15) = 2610 lb] . 

The estimated number of control signals required is 1500. Unshielded 
wire which weighs approximately 6.396 kg/10 3 m (4.3 lb/10 3 ft) can be used 
with these. The estimated total run length of these signals is 17 672 m 
( 58 x 10 3 ft) . Therefore, the wire weight for the control signals is 
17. 68 x 6.396 = 113.09 kg (58 x 4.3 = 249.4 lb). 

For discrete wiring, A/D converters are provided for some analog 
signals. Using 1613 analog signals at 0. 04536 kg ( 0.1 lb) for A/D converter 
per measurement, a value of 73. 01 kg (161 lb) is calculated. The total weight 
of the discrete wiring system is therefore the sum of the weights of the measure- 
ment wiring, control wiring, and A/D converters, i. e. , 11 83. 6 + 113. 09 + 73. 01 

1369.7 kg (2610 + 249 + 161 = 3020 lb). 

A block diagram for the Shuttle data management system is shown in 
Figure C-16. Because of the Shuttle ground rules, extensive redundancy was 
utilized in the DMS. The length of the data bus was estimated to be 182. 93 m 
( 600 ft) . At 22. 31 kg/10 3 m ( 15 lb/l x 10 3 ft) , a weight of 4. 08 kg (9 lb) is 
obtained for one bus. Because of the redundancy requirements, five buses 
were used yielding a total bus weight of 20.41 kg (45 lb). 

The weight of the ACT units, tranformer coupling units, and bus con- 
trol units are given below: 


250 ACT units at 0.4536 kg (l lb) /unit 


1250 transformer coupler units at 0. 09072 kg 
(0.2 lb) /pair 


4 bus control units at 2. 268 kg ( 5. 0 lb) /unit 


113.375 kg 
(250 lb) 

113.375 kg 
(250 lb) 


9.07 kg 
(20 lb) 

235. 82 kg 
( 520 lb) 
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BIU = BUFFER INTERFACE UNIT 
ACT = ACQUISITION. CONTROL, AND TEST 
= FUNCTIONAL FLOW ON DATA BUS 


Figure C-16. Common bus control unit — data bus management 
















The ACT and transformer coupling units basically serve the purpose of the DIU 
unit in the Spacelab. 

Wiring from ACT to bus and ACT to black boxes is estimated to be 250 
ACTs x 9.15 m (30 ft) (av)x 10 (No TSP) - 34 012. 5 m (75 x 10 3 ft), assuming 
22.31 kg/10 3 m (15 lb/lx 10 3 ft) wire weight yields 34. 012 x 22. 31 = 751. 68 kg 
( 75 x 15 = 1125 lb). 

The total DMS system weight is estimated to be 20.41 + 235. 82 + 510. 19 
B 766. 42 kg (45 + 520 + 1125 = 1690 lb) . A saving of 603. 29 kg ( 1330 lb) has 
resulted from the utilization of a DMS over discrete wiring. This is a saving 
of approximately 44 percent in the discrete wire system weight. Notice that 
this is for a redundant system. For a single thread (simplex) system, the 
DMS weights would be approximately: 


Data bus 0. 183 m x 22. 31 kg/l0 3 m 
(600 x 15 lb per 1000 ft) 

4.08 kg 
(9.0 lb) 

64 ACT at 0.453 kg/unit (1 lb/unit) 

29. 02 kg 
( 64. 0 lb) 

256 transformer coupler units at 0.0917 kg 
( 0. 2 lb) each 

23. 22 kg 
(51.2 lb) 

1 bus control unit 

2.27 kg 
( 5. 0 lb) 

64 ACT to bus and ACT to black box wire weight 

130. 61 kg 
(288.0 lb) 


189.11 kg 
(417.0 lb) 


A similar analysis was made concerning volume. Point-to-point wiring 
required 1.16 m 3 (71 027 in. 3 ) while approach required 0. 546 m 3 (33 300 in. 3 ) , 
or a saving of 52 percent. This again is for a redundant system. 

Although the results of this effort were obtained specifically for Shuttle, 
the relative merits gained through the DMS approach are believed to be applicable 
to any application. That is, it is believed that approximately 50 percent can be 
saved in weight and volume through the use of an integrated DMS. Due to flex- 
ibility, turnaround time, refurbishment, etc. , the DMS approach becomes even 
more desirable and may be the only reasonable approach in Spacelab. 
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The current Shuttle data bus approach is a multiplexer/demultiplexer 
dedicated line system and not a generalized two wire system as currently 
proposed for Spacelab. 


C4. 3. 3. 2 Ease of Reconfiguration 

One factor influencing the design of a Spacelab DA&D system is the need 
for periodic reconfiguration of parts of the system. As experiment comple- 
ments are changed from mission to mission, it must be possible to reconfigure 
the data system at reasonable cost and within a reasonable time. 

To reconfigure the data bus system, assuming that no change in system 
size is required, it will be necessary to remove the old experiment sensors and 
install the new hardware. The new equipment will have prepared cables which 
will mate with connectors on the DIU. A new software package, debugged on a 
simulator, will be loaded into the computer system and re verified, to complete 
the reconfiguration. 

To reconfigure the conventional system, again assuming no size change 
is needed, it will be necessary to exchange the experiment sensor hardware, 
replace the computer software and reconfigure the distributor. Several options 
are available for reconfiguring the distributor. The distributor could be 
rewired while still onboard but the serial time required would be excessive. 

A replacement distributor, prepared in advance, can be installed in place of 
the old one. The replacement distributor must be prepared for use by instal- 
ling the proper set of interconnect wires. This could be done by using the FAC 
system comprising a computer and display device which uses raw running list 
data to generate a display showing the operator where to locate each wire. If 
more automation were deemed necessary, a computer- controlled automatic 
wire- wrap machine could perform the same function. Since reconfiguration 
of this concept requires more physical replacement and modification of hard- 
ware, it can be anticipated that more time will be needed to verify the change 
and that there will be more possibility for hardware and harness failures. 


C4.3.3.3 Growth 

The data bus concept described here can be enlarged to as many as 32 
DIUs by installing the DIUs, tapping them onto the data bus, cabling the sub- 
system into the DIU’s standard interface, and loading appropriate software. 


265 



Enlarging the conventional system after is is built is not at all easy, 
in fact it appears that certain parts of the system must be sized when first 
installed for the maximum configuration. The number of digital outputs can 
be increased by adding more switch selectors and output wiring. The number 
of multiplex/recording inputs can be increased by increasing the number of 
remote multiplexers and adding more input wiring. The addition of more analog 
or discrete inputs for onboard use is not so straightforward. If the number of 
lines available in one junction box is not adequate, it is necessary to add another 
box, another cable to the interface bulkhead, another penetration of the inter- 
face bulkhead, another cable from the interface bulkhead to the distributor, and 
a distributor with capacity to handle another cable. Modifications of this extent 
are probably not practical to perform as a routine part of reconfiguration, so 
the system would be built with all the internal cabling, distributors, and inter- 
face penetrations for the worst-case mission. It may be practical to remove 
junction boxes and their cables to the interface when not needed but the 
remainder of the system will become resident hardware and will fly whether 
it is used or not. 


C4.3.3.4 Cost 

The design and development costs of a data bus system have to be 
larger than those of a conventional hardware system because of the design 
complexity. The data bus has a cost advantage due to its ease of expansion 
and/or reconfigurability. However, there are no actual data to verify this 
conclusion as this advantage is somewhat intangible. 


C4.3.3, 5 Power 

The data bus system will require some additional electrical power. 

The amount of power is dependent primarily on the number of remote terminals 
and their ’'on” time. For the Spacelab system, this power requirement is 
expected to be on the order of 100 to 300 watts. 

In summary, a comparison matrix was assembled where the com- 
parison criteria were weighted and rated for each approach. This comparison 
matrix is presented in Table C-15 and shows a significant advantage in using 
the data bus for Spacelab. This advantage is primarily in the savings that 
can be obtained in implementing the experiment changeovers between missions. 
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TABLE C-15. HARDWIRE VERSUS DATA BUS TRADE STUDY MATRIX 


Evaluation 


Hardware 

Data Bus 

Criteria 

Weighting 

Rating 

Total 

Rating 

Total 

Weight 

5 

5 

25 

9 

45 

Volume 

5 

5 

25 

8 

40 

Ease of 

R econfiguration 

10 

7 

70 

10 

100 

Growth 

8 

2 

16 

8 

64 

Cost 

10 

9 

90 

5 

50 

Power 

7 

10 

70 

58 

56 

Total 



296 


355 


C4.4 DATA BUS DEVELOPMENT STATUS 

The following two sections provide a discussion of the data buses under 
development and their status within NASA. 


C4.4.1 CVT Data Bus 


MSFC has under development and test a data bus that had its origin in 
the Space Station Phase B Study. The hardware presently under test at MSFC 
is representative of the modular station configuration and has the following 
components and characteristics: 

1. Bus Interface Unit — Provides the interface between the processor 
and bus. 

2. Data Bus Terminal — Provides the subsystem communications. 

3. Remote Data Acquisition Unit — Provides the interface to the sub- 
system with a capability of 16 discrete outputs, plus 30 analog and 16 discrete 
inputs. 
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4. Display Interface Adapter — Provides the interface between the 
Data Bus and the Multifunction Display System. 

The system is in operation/test using an XDS-930 computer, with 
executive software and data bus application software. This basic system 
operates in the 10 Mbs range between the CIU and the data bus terminal ( DBT) 
and between the DBT and the remote data acquisition unit (RDAU) . 

The bus operation is a frequency division multiplex/time division multi- 
plex ( F DM /TDM) combination and can be implemented on three 20 MHz wide 
channels operating at 240 MHz, 280 MHz, and 310 MHz. Presently, only one 
channel (240 MHz) has been implemented. 

The software scheme for bus operation consists of an 18-bit, A, B, 

D, and C word sequence, where the A word is the DBT Address, the B word 
the subsystem address and action code, the D word is data, and the C word 
is status and end of message. Simple parity is used for error detection. 

A new data bus is presently being implemented in the CVT facility to 
support Spacelab operational and integration tests. This new data bus is the 
design that resulted from these Phase B studies. 


C4.4.2 Space Shuttle Data Bus 

The Space Shuttle data bus design has not yet reached the fabrication 
and test status. However, considerable studies, analysis, and preliminary 
design activity has been conducted. The following provides a brief description 
of the Shuttle Orbiter DMS and includes a description of the Shuttle Or biter 
data bus. 

The current Orbiter DMS baseline consists of five identical 65K/32 bit, 
general purpose computers and five input/output boxes (IOB). One IOB is 
associated with each computer for input/output operations. During launch, 
three computer /IOB combinations are dedicated to guidance, navigation, and 
control (GN&C), but during on-orbit operations, only one is dedicated to GN&C 
and the other two are available as spares. The remaining two computer/lOBs 
are used for mission specialist station operations and payload/manipulator 
operations . 
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The computers interface with Orbiter subsystems through the IOBs. 
Each of the five IOBs has the capability to interface with up to 32 serial digital 
data bus channels (26 presently planned with 6 growth). The data bus channels 
are 1 Mbs serial digital links with a transmit line for commands and a separate 
receive line for data from subsystems. Each serial digital link provides the 
capability of interfacing with up to 31 MDM units, which in turn interface with 
subsystem components. Therefore, each IOB could conceivably interface with 
over 900 MDMs. 


C4. 5 RATIONALE FOR A 2 Mbs DATA BUS 

This section is to provide rationale and background information concern- 
ing the 2 Mbs data bus which was baselined in the Spacelab Design Reference 
Model and which is being designed for CVT. 

Spacelab subsystem data flow analysis yielded rates of approximately 
100 kbs for orbital operation and approximately 125 kbs for autonomous, 
onboard, prelaunch checkout. These are rough estimates of raw data require- 
ments and do not include provisions for bus control and overhead which may be 
as high as 100 to 150 kps. Based on present information and planning, total 
subsystem requirements would yield rates no higher than 300 to 500 kps. 
Although in the Spacelab baseline the high rate experimental data (50 to 70 Mbs) 
did not utilize the data bus, provisions were included for experimental control 
and some limited experiment processing. However, due to lack of definition, 
a reasonable estimate of the experimental data associated with these functions 
is not possible at this time. 

In any data bus system, it is very unlikely that the maximum bus rate 
would be utilized for any appreciable length of time; i. e. , one may see bursts 
at the maximum rate for very short periods of time, but the average rate over 
time intervals of minutes would be only a small percentage of the maximum 
rate. (The percentage itself would naturally be dependent upon the overall 
system requirements) . However, the key factor governing the DMS bus rate 
is not necessarily the data flow rates but, rather, overall system requirements 
such as response time, etc. 

The Spacelab baseline which is being implemented in CVT provides for 
expansion of up to 32 DIUs. (Between 6 and 10 DIUs have been defined for 
Spacelab, depending on the particular payload. ) Numerous operating system 
schemes ( software) were considered for Spacelab; one was to allow the DIUs 
to interrupt the computer when it had information available. For several 
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reasons, DIXJ interrupts were not allowed but rather an operating system scheme 
was chosen whereby the computer services, samples, or interrogates the DIUs 
on a cyclic basis. Thus, for example, a finite period of time is required 
between successive samples of discrete input changes from a particular DIU. 

The basic bus rate, therefore, determines the response time of the computer 
system to a subsystem DI change as presented to the DMS by the DIU. 

One of the requirements imposed on the Spacelab DMS by onboard check- 
out and monitoring subsystem was to be able to respond to DI changes within 5 
msec. This DI response time appears to satisfy the other Spacelab subsystem 
requirements as well and to be reasonably based on experience in other pro- 
grams. Since the Spacelab DMS can have up to 32 DIUs, each with a maximum 
of 128 DIs, and since it is desired not to allocate more than 20 to 25 percent 
of the effective data bus rate to the discrete monitoring function, a 2 Mbs data 
bus is required to provide a 5 msec response. Doubling the bus rate will 
essentially halve the response time and halving the bus rate will double the 
response time. 

In regard to data bus design and technology, a single approach and design 
can be used for rates up to approximately 4 or 5 Mbs by simply changing the 
basic clock frequency, providing the components have been specified for the 
higher rate; i. e. , higher rates require tighter component specifications but the 
same number of components will be required for any rate within this range. 

Some overall design margins will be sacrificed as the rates are increased, but 
rates up to 5 Mbs can be provided with sufficient design margins. (Rates and 
bus lengths can be correlated and have been taken into consideration here. ) 
However, the computer load necessary to control the data bus will depend 
greatly on bus rate; it is estimated that the baselined Spacelab input- output 
processor can control up to three 2-Mbs data buses. 

To summarize, the following points are made: 

1. Data bus rates, including bus control and overhead, are estimated 
from Spacelab subsystem requirements to be of the order of 300 to 500 kbs. 

2. Experiment data rates for limited experiment processing and control 
are not presently defined. However, the 2 Mbs data bits can provide for the 
anticipated experiment control and a limited amount of experiment processing. 

3. Data rates alone do not necessarily dictate data bus operating rates; 
i. e. , consideration must be given to the system response time requirement 
which in Spacelab has been estimated to be 5 msec. 
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4. From a design viewpoint, and with today T s technology, a single bus 
design can be used to provide operating rates up to 4 or 5 Mbs, 

5. The 2 Mbs data bus baselined for Spacelab and being implemented in 
CVT will provide as much capability as is expected to be required (although the 
experiment requirements are presently undefined) and at the same time maintair 
a conservative design by keeping design margins within reasonable limits. 

6. The baselined Spacelab and CVT provides for additional buses (up to 
an estimated total of three) without impact on the DMS design. One or two of 
these buses could be dedicated to experiment operation if desired or necessary. 


C4.6 SUMMARY 

From the studies performed to date, the data bus system is the best 
choice for performing the data acquisition and distribution function in the Space- 
lab. However, followup activity and control is required to insure that the final 
design of the data bus does indeed provide the growth and ease of reconfiguration 
needed for the Spacelab DMS. 

C5.0 SPACELAB ANALOG SIGNAL CONDITIONING TECHNIQUES 
C 5. 1 INTRODUCTION 

In general, in-flight analog performance monitoring measurements 
require signal conditioning before being presented to a data management or 
telemetry system. Signal conditioning serves to restrict voltage levels to 
within acceptable levels and to provide isolation from the signal source and 
telemetry or data management system. With programmable gain amplifiers, 
it is possible to time-share signal conditioners with a possible reduction in 
hardware and cost. The objective of this study is to evaluate such a system 
and an alternative system for Spacelab. 


C5.2 APPROACH 

Analog measurements will interface with the Spacelab data bus via a 
digital interface unit as shown in Figure C-17. Each DIU can accommodate up 
to 128 analog inputs with 8-bit A/D conversion. For this study, it is assumed 
that the maximum sample rate on any given DIU analog input is 50 samples per 
second. The input voltage requirement is 0 to 5 volts, inclusive. 
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CAPABI HTY/DIU 



128 {NOTE 1) 


128 (NOTE II 


128 (NOTE 2) 


4 (NOTE 2) 


8 CHANNELS (NOTE 3) 


NOTES: 

1. MAY BE GROUPED USING ADJACENT Dli/DOs FOR 
PARALLEL DIGITAL INPUTS/OUTPUTS. 

2. EIGHT-BIT RESOLUTION PROVIDED IN ANALOG-TO- 
DIGITAL AND DIGITAL-TO ANALOG CONVERTERS. 

3. DATA TRANSFER IS SERIAL AND AT DATA BUS RATE. 


Figure C-17. DIU interface. 

The Spacelab measurement and control list summary was reviewed to 
obtain the number of measurements and sampling requirements for the Space- 
lab susbystems and an experiment. Experiment MS/MS-2.3 was chosen 
because the sampling rates would require the greatest number of signal con- 
ditioners for time sharing purposes. Table C-16 identifies the sampling rate 
requirements. Sampling rates greater than 50 s/s require dedicated signal 
conditioners and special data handling techniques and, therefore, are not 
included in this study. Analogs within the 10 to 100 s/s category are considered 
to have sampling requirements of 50 s/s. For the other categories, the 
required sampling rate is assumed to be the upper bound of that classification. 
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TABLE C-16. SPACE LAB ANALOG MEASUREMENT LIST SUMMARY 



Analog Signals ( Sample Rate/sec) 

Subsystem/Experiment 

0 to 0. 1 

0.1 to 1 

1 to 10 

10 to 100 

Stability and Attitude Control 


67 

27 

1 

Data Management 


13 



Electrical Power 

79 




Environmental Control and Life Support 

32 

13 

77 


Thermal Control and Structure 

58 




Experiment MS/MS-2.3 


170 

126 

5 

Total 

169 

263 

230 

6 

Estimated Number Not Sharing Signal 
Conditioners 

66 

135 

65 

6 

Estimated Number Sharing Signal 
Conditioners 

103 

128 

175 

0 



Spacelab measurement names, ranges, and signal characteristics were 
not available. Therefore, the Skylab Orbital Workshop (OWS) and Airlock 
Module measuring lists were used as a guide in approximating the net number 
of measurements that would time-share signal conditioners (reference Table 
C-16) . Some measurements do not share signal conditioners for one or more 
of the following reasons: 

1. The signal is already 0 to 5 volts and does not require isolation from 
the telemetry or data management system. 

2. The transducer and signal conditioning device must be calibrated 
together. 

3. The signal must be sampled at 50 s/s or greater, which precludes 
the possibility of time sharing of a signal conditioner. 


C5. 3 SIGNAL CONDITIONING TECHNIQUES 

Two possibilities of signal conditioning were evaluated. One technique 
involves time sharing of the signal conditioners and the other proposes dedicated 
signal conditioners for each analog signal. 

In each of the methods, all analog signals are routed through a component- 
labeled measuring distributor. The measuring distributor, if incorporated, 
would perform the following functions: 

1. Serve as a convenient interface to the multiplexers. 

2. Could be used to switch out/in measurements into the same analog 
input channels of a particular DIU. 

3. Assist in pre-flight checkout of measurements. 

4. Scale input voltages to an acceptable level for input into a signal 
conditioning device. 

5. Serve as a means of routing operating power to transducers. 
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C5. 3.1 Time Sharing Signal Conditioners 


A method of time-sharing signal conditioners is shown in Figure C-18. 
The signal conditioners could be designed into the unit performing the multi- 
plexing but are shown separately here for ease of illustration. To satisfy the 
sampling requirements, approximately 38 programmable gain signal con- 
ditioners would be required. It is assumed that the conditioners are off-the- 
shelf items with eight selectable gain ranges. Gain selection would require 
three DOs from DIUs to each signal conditioner. Synchronization and timing 
would originate in the Spacelab computer. Assuming maximum utilization of 
multiplexing and time- sharing capabilities, only one DIU would be required. 

This type system would require minimum power and minimum hardware 
cost. To optimize the time-sharing and gain capabilities of the signal con- 
ditioners, much planning would be required from mission to mission to route 
the measurements and to program the gain switching. Because of multiple gain 
limitations for each signal conditioner and the varied number of measurements 
per mission, accuracy of some measurements would be degraded because full 
scale resolution may not be possible, A single signal conditioner failure could 
eliminate as many as 143 of the measurements. Since payload operation is the 
prime mission objective and because of the importance of the analog measure- 
ments in the event of subsystem or experiment malfunction, it is desirable to 
eliminate this single point failure. This could be done simply by making the 
signal conditioner redundant. Depending on sampling requirements, an 
additional DIU may be required to provide the additional digital outputs to per- 
form signal conditioner and gain selection in the event of failure. 


C5. 3.2 Dedicated Signal Conditioners 

The dedicated signal conditioning technique presented in Figure C-19 
requires 406 signal conditioners, 368 more than time-sharing conditioners 
assuming no redundancy. Only one measurement is lost per signal conditioner 
malfunction. Full scale resolution of each measurement is possible because 
the gain and input can be matched accordingly. Because the problems of pre- 
programming a signal to a given conditioner to optimize multiplexing and gain 
selection do not exist, this technique has much more flexibility over time- 
sharing conditioners. 

Only one DIU is required to format the measurements into the DMS. 
This technique does require more power and would involve more hardware cost 
than the time-sharing technique. 
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Figure C-18. Time-sharing signal conditioners 
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Figure C-19. Dedicated analog signal conditioning. 
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C5.4 SUMMARY 


Table C-17 is a chart summarizing the two techniques. Dedicated signal 
conditioning is the obvious choice for maximum data quality. This technique is 
more reliable, has greater flexibility and overall data accuracy is greater 
than with time- sharing technique. 

It is difficult to arrive at power requirements and hardware costs because 
the analog signal characteristics and signal conditioning requirements were not 
available. Therefore, specific signal conditioners could not be selected. Only 
a rough order of magnitude comparison is made in the table. 

There are other signal conditioning techniques; however, experiment 
operation and data management are the prime objectives of Spacelab. There- 
fore, it is important that performance data always be available and of the high- 
est quality possible. A system that will fulfill these requirements, even with 
increased hardware cost and power, is recommended. 


C6.0 PACS TO DATA BUS INTERFACE 
C6. 1 INTRODUCTION AND SCOPE 

The implementation of the pointing and attitude control subsystem, as 
presently defined, requires extensive use of software, and this software is 
processed in the DMS digital computer. This software includes the nagivation 
equations, the C MG and SEPB control laws, and others. Implementation of 
these equations and/or control laws in software requires extensive and rapid 
data flow between the PACS hardware and the DMS digital computer. 

Most data to and from the hardware are analog and the data, as trans- 
ported on the data bus, to and from the computer is digital. Three approaches 
for implementing this interface and the hardware required for each are defined 
in this section. This study is directed toward the primary signal flow required 
to implement the primary PAC functions. Housekeeping, status measurements 
on-off controls, etc, , are not included. 


C6.2 STUDY RESULTS 
C6.2.1 Physical Interface 

To minimize the electrical noise problem, it is desirable to convert 
from analog to digital as early as practical and from digital to analog as late as 
practical. Thus, the ana log -to -digital converters (ADCs) and digital-to-analog 
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TABLE C-17. TIME-SHARING CONDITIONER AND DEDICATED SIGNAL CONDITIONER SUMMARY 


Parameter 

Time-Sharing 
Signal Conditioner 

Dedicated 
Signal Conditioner 

Reliability 

Loss of one signal conditioner could result in loss of 
up to 143 measurements. 

Reliability could be improved by having redundant 
signal conditioners at the expense of computer 
software. 

Only one measurement lost per 
signal conditioner failure 

Accuracy 

Full-scale resolution of each measurement may not 
be possible due to the available gains of the signal 
conditioner and multiplexer requirements. 

Full-scale resolution available on 
all measurements. 

Flexibility 

Limited by gains of the signal conditioners and 
programming required to maximize multiplexing. 

Maximum flexibility. 

Power 

Requirements 

Each DIU requires 70 watts. Signal conditioner 
power requirement is approximately 0. 1 of dedi- 
cated signal conditioners. 

DIU 70 watts. Approximately 10 
times as much power required for 
signal conditioners versus time- 
sharing techinque. 

Hardware Cost 

One, possibly two, DIUs at $50K each. For redun- 
dancy, approximately 76 signal conditioners are 
needed with cost estimated to be one-fourth that of 
dedicated signal conditioners. 

$50K for one DIU. The required 
406 signals are estiamted to cost 
about four times that of time- shared 
signal conditioners. Signal condi- 
tioner cost is estimated to be less 
than one- third that of one DIU. 

Software Cost 

Computer programming and planning required for 
each mission to maximize data quality and quantity. 

Little or no software impact. 



converters (DACs) should be located as near the PACS hardware as practical. 
Also, thermal conditioning is highly desirable for the ADCs and DACs to help 
obtain the needed accuracy. 

To help minimize the electrical noise problem, it is assumed that two 
DIUs are available. One would be located at or near the pallet-mounted rate 
gyros or CMGs and one would be located at or on the SEPB. 


C6. 2.2 Signal Interface 

The interface with the data bus is provided through the DIU and its 
capabilities are illustrated in Figure C-17. In interfacing the PACS to the 
DIUs, two problems are encountered: 

1. The 8-bit resolution provided in the Als and AOs is considered 
inadequate for the primary PACS signal flow. 

2. Because only four AOs are provided per DIU, four DIUs are required 
for interfacing the PACS. 

The bit resolution limitation drives the requirement for special ADC and 
DAC with their associated switching and sample and hold circuits. Providing 
these ADCs and DACs permits using either the DIs and DOs or the RI/RO 
channels for the interface. The following paragraphs define three approaches 
for implementing this interface using the DIs and DOs, and the RI/RO channels. 


C6. 2. 2. 1 Approach A 

Approach A is a minimum additional hardware/cost approach and is 
illustrated in Figure C-20. The additional hardware required is two ADCs 
plus their associated multiplexers and sample-and-hold circuits, and 14 DACs, 
Multiplexing (analog) was not used with the DACs because of their relative low 
cost and size and, also, some improvement in performance was obtained. Two 
switch matrices (digital) were used in the fine guidance sensor input-output 
lines and one in the SEPB output to minimize the DIs and DOs used in order to 
hold the required number of DIUs to two. The disadvantage of this appraoch is 
the high sample rate (180 times/sec max) required in the DIU. 


280 



281 


4 OQs 



Figure C-20. PACS to DIU interface. Approach A. 












C6.2.2. 2 Approach B 

Approach B, illustrated in Figure C-21, was designed to limit the 
sample rate at the DIU to 50 times per second. The additional hardware 
required is 6 ADCs (3 with associated multiplexing and sample-and-hold 
circuits) , and 14 DACs. As in Appraoch A, three switch matrices (digital) 
were used to minimize the DIs and DOs used in order to hold the required 
number of DIUs to two. The disadvantages found for Appraoch B were the 
requirement of six ADCs, which are relatively high-cost items, and the prob- 
ability that three DIUs will be needed when the housekeeping functions are 
added. 


C6.2.2.3 Approach C 

Approach C, illustrated in Figure C-22, was designed to use the RI/RO 
channels for interfacing with the DIUs. The additional hardware required is 2 
ADCs with their associated multiplexers and sample-and-hold circuits, 14 
DACs, and 2 buffer-controllers. The buffer-controllers provide: 

1* Timing and controls for collecting and converting the input data 
and storing it in the input buffer. 

2. Formatting, as required, to transmit input data on the RI/RO 
channel. 

3. Receipt and storage of output data received on the RI/RO channel. 

4. Timing and controls for routing the output data from the output 
buffer and performing necessary conversions. 

The disadvantages of this approach are: (l) the addition of the two 
buffer-controllers and (2) possible timing and control problems unless, in 
the final design, some limited timing and control is provided through the DIU 
from the computer to synchronize the overall operation. 


C6.3 SUMMARY 

All three approaches are considered to be fully workable. Approaches 
A and B are somewhat more desirable in that no new design hardware is 
required, and the central computer maintains control over the overall data 
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Figure C-21. PACS to DIU interface, Approach B. 
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Figure C-22. PACS to DIU interface, Approach C 




















flow and processing. Assuming it is needed to limit the data rates of the DIs 
and DOs at the DIU to 50 times per second or less, then the needed additional 
hardware for Approach B is: 

1. 6 ADCs, 3 of which have multiplexers and sample-and-hold circuits. 

2. 14 DACs, with switching matrices (digital multiplexer). 

3. 1 additional DIU (probably). 

Should the buffer- controller needed for Approach C become an available 
hardware item for use in interfacing with the RI/RO channels, then this approach 
would be the minimum additional hardware approach. For Approach C, the 
needed additional hardware is: 

1. 2 ADCs, both of which have multiplexers and sample-and-hold 
circuits. 

2. 14 DACs, with switching matrices. 

From this cursory study, no timing problems were identified either in 
using multiplexers with the ADCs or DACs or due to expected delays added in 
the overall CMG or SEPB control loops. 

C7.0 LOGIC FAMILY SELECTION AND DESIGN CONSIDERATIONS FOR THE 
SPACELAB DATA MANAGEMENT SUBSYSTEM 

C7. 1 FAMILY SELECTION 

The Schottky-clamped TTL logic family appears well suited for the 50 
megabit portions of the Spacelab DMS. Only two existing logic families provide 
the necessary speed for 50 megabit data rates, Schottky-clamped TTL and ECL. 
A comparison of the features of the two logic types can be found in Reference 27. 

Some of the reasons for the preference of Schottky TTL over ECL for 
this application include: 

1. Ease of interface with existing equipment. 

2. Higher noise immunity. 

3. Lower power consumption. 
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C7. 2 SCHOTTKY-C LAMPED TTL DESIGN CONSIDERATIONS 


Design and layout considerations for high speed logic and, in particular, 
Schottky- clamped TTL can be found in References 28 through 30. Many of the 
considerations for ordinary TTL apply, but the 3-nsec propagation delay times 
and associated rise times of Schottky- clamped gates require that system inter- 
connections be treated as transmission lines. 

For printed circuit boards, microstrip transmission lines perform well 
at data rates to be used in the Spacelab data management system. Microstrip 
construction is shown below. 
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Transmission lines used with Schottky TTL should have approximately 
100 ohms characteristic impedance, z 0 , as given in Reference 31. 
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where D^ is the relative dielectric constant. 


Crosstalk between adjacent lines is, as shown in Reference 31, a function 
of conductor width and thickness, spacing between conductors, distance of 
conductor from ground plane, and dielectric constant. For line widths between 
1.91 and 6. 35 x 10 4 m ( 7. 5 and 25 mils) , crosstalk constants vary only about 
0. 5 percent with the width. These constants decrease with increasing line 
spacing and increase with height above ground plane, as would be expected. 


286 



Not only gate delay but also transmission line delay must be taken into 
account to assure proper operation of high-speed Schottky systems. The time 
delay, in nanoseconds/foot is given by 


T d = 1.017 \f 0.4750^ + 0.67 


Logic should be laid out so as to provide minimum interconnection lengths. 
Total delay times of signals that are to be combined should be matched. 
Branching of transmission lines should be avoided to preserve transmission 
line impedance. One single line should leave the driving point, with high 
impedance taps located along the line as necessary. 

Assuming a reasonable safety margin in total gate delay within logic 
circuitry, Schottky TTL systems may use single wire interconnections for 
lines not exceeding 0. 1524 m ( 6 in. ) in length. For lines longer than 0. 1524 m 
( 6 in. ) but less than 0. 254 m ( 10 in. ) , twisted pair lines [ 0. 762 turns/meter 
(30 turns/foot) , AWG 26 or AWG 28 wire] are recommended. Coaxial cable 
of approximately 100 ohms characteristic impedance can also be used. 

A 500 to 1000 ohm resistive pullup at the receiving end of long cables 
increases the noise margin and decreases rise times. Negative undershoot 
can be prevented by reverse termination with 27 to 47 ohms. Ground returns 
should be carried through at both the transmitting and receiving ends. 


C7.3 CONCLUSIONS 

Schottky- clamped TTL is recommended for use in Spacelab high data 
rate systems. System interconnections in high speed Schottky systems must 
be treated as transmission lines. The necessity of keeping interconnections 
makes multilayer micro strip boards attractive. Where cabling must be used, 
90 to 100 ohm coax or twisted pair is recommended. 
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APPENDIX D. SPACELAB 
CONTROLS AND DISPLAY SUBSYSTEM 


preceding page blank not fmcm 



D1.0 INTRODUCTION 


The current design reference model for the Spacelab controls and dis- 
play subsystem is defined in this section. 


Dl.l SCOPE 

Three control and display consoles are required. One is required for 
use in the pressurized Support Module plus a preentry C&D console to be 
located in the Shuttle Orbiter. For the Spacelab Pallet-Only configuration, a 
Pallet-Only C&D console is provided and is located in the Orbiter. 


Dl.2 APPLICABLE DOCUMENTS 

The following documents form a basis for the C&D concepts described 

herein: 


1. Task 2.4.1 Report, Sortie Lab Controls and Display Subsystem 
Requirements, dated May 7, 1973. 

2. Task 4. 1. 1 Report, Sortie Lab Design Requirements, dated Dec. 1, 

1972. 

3. Avionics System Functional Requirements, dated March 8, 1973. 

4. Memorandum S& E-AERO-MX-8-73, Definition of Sortie Lab Pay- 
loads Accommodated in a Pallet Only Mode, dated February 27, 1973. 


D2. 0 CONSOLE DESCRIPTIONS 


C&D console configurations have been defined for Spacelab Missions 
where both Support and Experiment Modules are flown and for missions where 
only a Pallet is flown. On missions where a Support Module is flown, checkout 
and operations control will be provided by the Support Module C&D console and 
the Spacelab preentry C&D. The preentry C&D may be located in the Orbiter 
in the space provided for the payload specialist station. On Pallet-Only mis- 
sions, operations control will be provided by a C&D located in the Orbiter. 



D2. 1 SUPPORT MODULE C&D CONSOLE 


The Support Module C&D console provides the capability for two-man 
independent operation and provides the central control for Spacelab subsystems 
and experiments during orbital operations. The Support Module C&D console 
will be interfaced to the Spacelab computer, other subsystems, and experiments 
by the data management subsystem data bus. Limited hardwire connections 
will be provided for selected critical functions and special experiment signals 
which do not readily lend themselves to data bus transmission. 

The C&D console (Fig. D-l.) includes multifunction controls and displays 
for both subsystems and experiments, dedicated controls and displays for sub- 
systems, and approximately 0. 334 m z (684 in. 2 ) of panel space for dedicated 
experiment controls and displays. Figure D-2 is a block diagram of the Support 
Module C&D console. Duplicated major items are interfaced to the data bus 
through separate data interface units to enhance the overall C&D reliability. 


D2. 1. 1 Multifunction Display System 

Two multifunction display systems will be provided, one for each 
operator. Each consists of two CRT indicator units, one alphanumeric key- 
board, and one multifunction display symbol generator. Each will provide the 
capability for independent display of computer-generated alphanumeric and 
graphic data, as well as video information. 


D2. 1. 1. 1 CRT Indicator Unit 

A CRT indicator unit will consist of a 3. 55 m ( 14-in.) CRT with deflec- 
tion and video amplifiers, linearity correction, CRT protection circuitry, and 
high and low voltage power supplies. It will be capable of operating in stroke 
write only, raster scan only, or combination stroke write-raster scan display, 
modes. The two CRT indicator units within the multifunction display system 
can be operated in the following modes: 

1. One video and one computer generated display. 

2. Both video displays. 

3. One video and one combined computer generated and video display. 

The capability to display computer generated data on either, but not both, CRTs, 
is provided. 
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0.711 m (28 in.) 



21 

22 

22 

21 


A-A 


1. VIDEO SWITCHING UNIT 

2. COMPUTER CONTROLS 

3. ELECTRICAL POWER SUBSYSTEM 
DEDICATED C&D 

4. CONSOLE CIRCUIT BREAKERS 

5. ADVISORY PANEL 

6. CRT DISPLAY INDICATOR UNIT 

7. EXPERIMENT DEDICATED C&D 

8. CAUTION & WARNING 

9. (TBD) 

10. DATA ACOUISITION DEDICATED C&D 

11. ENVIRONMENT CONTROL SUBSYSTEM 
DEDICATED C&D 


12. PACS DEDICATED C&D 

13. ALPHANUMERIC KEYBOARD 

14. HAND CONTROLLER 

15. TAPE RECORDER CONTROLS 

16. MICROFILM TO VIDEO CONVERTER 
CONTROLS 

17. AUDIO UNIT 

18. CCTV CONTROLS 

19. VIDEO SWITCHING CONTROLS 

20. TIME DISPLAY UNIT 

21. MULTIFUNCTION DISPLAY SYMBOL 
GENERATOR 

22. MICROFILM TO VIDEO CONVERTER 


Figure D-l, Support Module C&D. 
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DATA BUS DATA BUS 



Figure D-2. Reference model Support Module C&D console block diagram 










D2. 1.1.2 Alphanumeric Keyboard 

The alphanumeric keyboard provides alpha, numeric, and special editing 
control keys. The alpha and numeric keys will be arranged in a standard type- 
writer format; the editing control keys will be arranged in a 3 x 4 key format. 
N-key roll-over error protection will be provided. Information manually entered 
on the keyboard will be displayed on the CRT before it is entered in the DMS 
computer. Selective editing of any character will be provided. 


D2. 1. 1. 3 Multifunction Display Symbol Generator 

The MFDSG will accept a digital data stream from the DIU and provide 
stroke write X and Y deflection and unblanking signals to a CRT indicator unit. 
Only one CRT indicator unit will be driven at a time by the MFDSG. The MFDSG 
will store the data instructions received from the DIU in its random access 
memory and will generate vectors, circles, and 8-bit ASCII code alphanumeric 
characters for stroke write CRT display. Display refresh will be accomplished 
by redrawing the display format from instructions stored in the RAM at a suf- 
ficient rate to eliminate flicker. The MFDSG RAM will provide sufficient 
storage capacity for at least four separate display skeletons. The MFDSG will 
also provide the interface circuitry between the alphanumeric keyboard and the 
DIU plus the circuitry necessary for the display and editing of data entered on 
the keyboard before it is transmitted to the DIU. 


D2. 1. 2 Video Switching Unit 

The video switching units, one for each crewman, will be provided in 
the Support Module C&D console. A single video switching unit will switch all 
CCTV channels, experiment video channels, and the microfilm video converter 
output to the CRT indicator units as shown in Figure D-2. The video switching 
unit will be manually controlled by a crewman. 


D2. 1. 3 Microfilm -to -Video Converter 

Two microfilm-to-video converters, one for each crewman, will be 
provided. These units will convert cassette -microfilm- stored imagery to a 
1024 scan line, TV video signal for display on the CRT indicator units. The 
microfilm-to-video converter can be manually controlled by the crew or auto- 
matically controlled by the central processor via the data bus/DIU. 
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D2. 1. 4 Hand Controller 


Two 3 axis hand controllers, one for each operator, will be provided. 
The hand controllers will be used for pointing CCTV cameras, experiment 
telescopes, and cameras, and will provide inputs to the PACS for vehicle ma- 
neuvers and for slewing the standardized experiment pointing base. Backup 
manual pointing commands will be provided by alphanumeric keyboard entry. 
The hand controller will be a stiff stick type and will require three DIU analog 
channels with at least an 8 bit analog to digital conversion resolution. 


D2. 1. 5 Caution and Warning 

The Support Module C&D console will provide a C&W display panel for 
critical subsystems and experiments. The C&W indicators will be hardwired 
to their associated sensors and to the Orbiter C&W panel. 


D2. 1. 6 Advisory Display Panel 

The advisory display will be a computer driven alphanumeric display 
which provides the crewman with visual malfunction and operational instruction 
queues. The advisory display will have a digital interface with the DIU. A 
plasma, 256 character, self-scan panel is the most likely off-the-shelf hardware 
candidate for this function. 


D2. 1. 7 Time Display Unit 

The time display unit will provide the crew with a readout of mission 
time and a manually controllable countup- countdown event timer. The time 
base reference for the time display unit will be provided by the computer via the 
data bus. 


D2. 1. 8 Audio Center 


The audio center will provide the central controls for the Spacelab audio 
intercom systems. The intercom network will be hardwired to the various 
input/ output stations. 
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D2. 1. 9 Dedicated Subsystem C&D 

Dedicated C&Ds will be provided, where required, for the Spacelab sub- 
systems, as shown in Figure D-l. Dedicated subsystem C&Ds will be con- 
nected to its associated subsystem via the DIU/data bus. Selected critical and 
initial activation functions will be hardwired. 


D2. 1. 10 Dedicated Experiment C&D 

Approximately 0. 334 m 2 (684 in. 2 ) of panel space will be reserved for 
experiment supplied dedicated C&Ds. This equipment will also be connected 
to its associated experiment equipment via the DIU/data bus. A standard hard- 
wire interface capability will, however, be provided to both the Pallet and 
Experiment Module. This will include coaxial cables for high frequency signals 
for oscilloscope display. The display of analog waveforms not suitable for 
multifunction CRT or video monitor display will be accomplished by experiment- 
supplied oscilloscopes, pen recorders, or other such waveform display equip- 
ment. 


D2. 1. 11 Power Conditioning 

Console power conditioning equipment will be provided as required. 


D2. 1. 12 Weight, Power, and Volume Assessment 

Table D-l presents the mass, power, and volume assessment for the 
Support Module C&D console. 


D2. 2 PREENTRY C&D CONSOLE 

The preentry C&D console will provide those control and monitor func- 
tions needed prior to crew entry into the Spacelab habitable area. It will provide 
sufficient monitors of the habitable area status to ascertain that the area is 
safe for entry. The preentry C& D console performs the following functions: 

1. Displays environmetal data on the habitable area and selected equip- 
ment status. 

2. Controls the activation and deactivation of selected subsystems. 
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TABLE D-l. REFERENCE MODEL SUPPORT MODULE C&D 
CONSOLE WEIGHT, VOLUME, AND POWER ASSESSMENT 


Unit 

Number 
of Units 

Power 

(w) 

Width* Height* Length 
[m (in. ) J 

Volume 
[m s (in. 3 )] 

Weight 

Ike (lb) 1 

Video Switching Unit 

2 

4 

0. 24 * 0, 18* 0, 20 

0. 0174 


1 9. 07 




(9.0 * 7 * 8) 

(1063) 


(20) 

Computer Controls 

1 

2 

0. 24 * 0. l(i(i * 0. 102 

X 

irt 

0 

T 

10' 3 

4.54 




(9. 5 * 6. 5 * >i ) 

(247) 


(to) 

Electrical Power Subsystem Dedicated 

I 

4 

0.24 * 0.4:i* 0. 1(>(> 

0. 0163 


1 3. 61 

C&D 



(9.5 * 17.5* 0) 

(997) 


(30) 

Console Circuit Breakers 

1 

- 

0.24 * 0. Ul* 0. 102 

3. 1 1 * 

!0' 3 

4.08 




(9.5 * 5 * 4) 

(190) 


(»> 

Advisory Panel 

1 

40 

0.42 * 0. 18 * 0. 20 

0. 0156 


4. 54 




(17 * 7 * 8) 

(952) 


(10) 

CRT Display Indicator Unit 

4 

400 

0.42* 0. 27 X 0.42 

0.275 


54.42 




(17 * 14.5 * 17) 

(IK 760) 

(120) 

Caution and Warning 

1 

5 

0.42 * 0, 08 x 0. 20 

6.68 X 

10- 3 

2. 27 




(17 X 2 X 8) 

(406) 


(5) 

Data Acquisition Dedicated C& D 

1 

2 

0.24 * 0.08* 0. 102 

4.69 * 

in- 1 

4.54 




(9. 5 * 7. 5 * 4) 

(280) 


(16) 

environmental Control Dedicated C&D 

1 

10 

0.24 * 0. 22 X 0. 102 

8.09 x 

1O- 3 

9. 07 




(9. 5 X 13*4) 

(494) 


(20) 

PACS Dedicated C&D 

1 

2 

0. 24 * 0.22* 0. 102 

5.29 x 

10- 3 

4. 54 




(9.5* 3. 5 * 4) 

( 523) 


(10) 

Alphanumeric Keyboard 

2 

2 

0.43* 0.05 * 0. 14 

G. 1 3 X 

10- 3 

2. 27 




(17 * 2* 5.5) 

,(374) 


(5> 

Hand Controller 

2 

2 

0. 102 * 0. 20 * 0. 102 

X 

0 

C'J 

■^4* 

1Q- 3 

13.61 




(4*8*4) 

(256) 


(30) 

Tape Recorder Controls 

2 

2 

0.24 * 0. 15 * 0.08 

6. 14 x 

10- 3 

4. 54 




(9*6*3) 

(324) 


(10) 

Microfllm-to- Video Converter Controls 

2 

2 

0. 102* 0. 15 * 0.08 

2. 36 * 

10" 3 

4.54 




(4*6*3) 

(144) 


(10) 

Audio Unit 

2 

40 

0.13* 0.15* 0.06 

3.93 x 

10 -3 

6. 80 




(5X6*4) 

(240) 


(15) 

CCTV Controls 

2 

2 

0. 13* 0.15 * 0.08 

2.95 x 

II)- 3 

a. 63 




(5*6*3) 

(180) 


(8) 

Video Switching Controls 

2 

2 

0. 13 X 0. 15 * 0. 08 

2. 95 x 

10- 3 

3. 63 




(5*0*3) 

(180) 


(8) 

Time Display Unit 

1 

20 

0.43* 0,15* 0.08 

5.01 x 

10- 3 

2. 27 




(17*6X3) 

(806) 


(5) . 

Multifunction Display Symbol Generator 

2 

150 

0. 43 x 0. 20 x 0.41 

0. 0714 


27.21 




(17 x 8x 10) 

(4360) 


(60) 

Microfilm-to-Video Converter 

2 

80 

0. 43 x 0, 20 * 0. 31 

0. 0534 


18. 14 




(17 x 8x 12) 

(3260) 


(40) 

Console Wiring 

- 





20.41 







(45) 

Console Enclosure 

- 



3. 39 


136.05 





(206 800) 

(300) 

Total 


772 



353. 73 
(780) 








Dedicated Experiment C& D 


(10* 36 x TBD) 















This console is configured for one-man operation as shown on Figure D-3. 
Figure D-4 shows a block diagram of the preentry C&D console. 


D2. 2. 1 Multifunction Display System 

One multifunction display system consisting of two CRT indicator units, 
one alphanumeric keyboard, and one MFDSG is provided. The multifunction 
display system is identical to the one used in the Support Module C&D console 
described in Section D2, 1. 


D2. 2. 2 Other Nondedicated C&D Components 

The video switching unit, hand controller, C&W panel, advisory panel, 
and time display unit are the same as the units used in the Support Module C&D 
console described in Section D2.1. 


D2. 2. 3 Dedicated C&D 


Dedicated hardwired C&D as shown in Figures D-3 and D-4 will be 
provided for the data acquisition subsystem, CCTV, and electrical power sub- 
system. 


D2. 2. 4 Power Conditioning 

Console power conditioning equipment will be provided as required. 


D2. 2. 5 Reference Model Preentry C&D Console Weight, Power, and Volume 
Assessment 


Table D-2 presents the mass, power, and volume assessment for the 
reference model preentry C&D console. 


D2. 3 PALLET-ONLY C&D CONSOLE 

The Pallet-Only C&D console will provide the central control for Space- 
lab subsystems and experiments during orbit operations. It will be interfaced 
to the Spacelab computer, other subsystems, and experiments via the DMS data 
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1. MULTIFUNCTION DISPLAY SYMBOL GENERATOR 

2. ADVISORY PANEL 

3. CAUTION & WARNING 

4. COMPUTER & DATA ACQUISITION DEDICATED C&D 

5. CCTV CONTROLS 

6 TIME DISPLAY UNIT 

7. MULTIFUNCTION CRT DISPLAY INDICATOR UNIT 
B. VIDEO SWITCHING UNIT 

9. ELECTRICAL POWER SUBSYSTEM DEDICATED C&D 

10. AUDIO UNIT 

11. ALPHANUMERIC KEYBOARD 

12. HAND CONTROLLER 

13. HAND CONTROLLER MODE AND ENABLE CONTROLS 


Figure D-3. Preentry C&D console. 
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TABLE D-2. REFERENCE MODEL PREENTRY C&D CONSOLE 
WEIGHT, VOLUME AND POWER ASSESSMENT 


Unit 

Power 

(w) 

Width x Height x Length 
[ m ( in. ) 1 

Volume 
[m 3 (in. 3 )] 

Weight 
[kg ( lb) 1 

Display Control Unit 

75 

0. 32 x 0 . 20 x 0.41 
(12.5X 8 x 16) 

0.026 

(1600) 

11.34 

(25) 

Advisory Panel 

40 

0. 32 x 0 . 19 x 0.20 
(12.5X 7.5 X 3) 

0. 012 
(750) 

4.54 

(10) 

Caution and Warning 

5 

0. 32 x 0. 09 x 0. 20 
(12.5 x 3. 5 x 8) 

5. 74 x 10* 3 
(350) 

2.27 

(5) 

Computer and Data Acquisition 
Dedicated C&D 

5 

0. 32 x 0. 1 x 0. 1 
(12.5X 4X4) 

3. 28 x 10" 3 
(200) 

4.54 

(10) 

CCTV Controls 

1 

0 . 127 x 0 . 18 x 0.08 
(5X7X3) 

1. 72 x 10~ 3 
(105) 

1. 81 
(4) 

Time Display Unit 

20 

0.127 x 0.18 x 0.08 
(5X7X3) 

1.72 x 10“ 3 
(105) 

2.27 

(5) 

Video Switching Unit 

2 

0. 25 x 0. 127 x 0. 08 
(10x5x3) 

2.46 x 10~ 3 
(150) 

1.81 

(4) 

Multifunction CRT Display 
Indicator Unit (2) 

200 

0. 32 x 0. 30 x 0.41 
(12. 5 x 12 x 16) 

0.079 

(4800) 

27. 22 
(60) 

Electrical Power Subsystem 
Dedicated C&D 

4 

0. 51 x 0 . 127 x 0.1 
(20 x 5 X 4) 

6. 55 x 10- 3 
(400) 

6. 80 
(15) 

Audio Unit 

40 

0. 25 x 0. 127 x 0 . 1 
(10 x 5 x 4) 

3. 28 X 10- 3 
(200) 

4.53 

(10) 

Alphanumeric Keyboard 

2 

0.43 x 0. 05 x 0.14 
(17X2X5.5) 

3.06 x 10 -3 
(187) 

2.27 

5) 

Hand Controller 

1 

0. 1 x 0 . 20 X 0 . 1 

(4X8X4) 

2. 10 x 10~ 3 
(128) 

6.80 
(15) ' 

Hand Controller Mode 
and Enable Controls 

- 

0. 127 x 0. 14 x 0. 1 
( 5 x 5. 5 x 4) 

1. 80 x 10“ 3 
(no) 

0.91 

(2) 

Console Wiring 

- 

- 

- 

13.61 

(30) 

Console Enclosure 

- 

- 

0.524 
( 32 000) 

79. 38 
(175) 

Total 

395 


0. 524 
(32 000) 

170. 10 
(375) 
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bus. Limited hardwire connections will exist for critical start-up functions 
which must operate independently of the data bus. The Pallet-Only C&D 
console is configured for one-man operation, as shown on Figure D-5. The 
console includes multifunction controls and displays for both subsystems and 
experiments, dedicated C&Ds for subsystem control, and space for dedicated 
experiment supplied C&D components. Figure D-6 is a block diagram of the 
reference model Pallet-Only C&D console. 


D2. 3. 1 Multifunction Display System 

One multifunction display system consisting of two CRT indicator units, 
one alphanumeric keyboard, and one MFDSG will be provided. The multifunc- 
tion display system used in this console is identical to the one used in the 
Support Module and the preentry C&D consoles described in Section D2» 1. 


D2. 3. 2 Other Nondedicated C&D Components 

The video switching unit, microfilm-to-video converter, hand control- 
ler, C&W panel, advisory panel, and time display unit are the same as the 
units used in the Support Module C&D console described in Section D2. 1. 


D2. 3. 3 Dedicated Subsystem C&D 

Dedicated C&D will be provided for the Spacelab subsystem as shown 
on Figure D-4. Dedicated subsystem C&D will primarily be connected to its 
associated subsystem via the DIU/data bus. Selected critical and initial acti- 
vation functions will be hardwired. 


D2. 3. 4 Dedicated Experiment C&D 

Approximately 0. 334 m 2 (684 in. 2 ) of panel space have been reserved 
for dedicated experiment C&D equipment. This equipment will also be con- 
nected to its associated experiment equipment via the DIU/data bus. 


D2. 3. 5 Power Conditioning 


Console power conditioning equipment will be provided as required. 




1. DEDICATED EXPERIMENT C&D 

2. ADVISORY PANEL 

3. THERMAL CONTROL SUBSYSTEM DEDICATED C&D 

4. PACS DEDICATED C&D 

5. MULTIFUNCTION CRT INDICATOR UNIT 

6. MICROFILM TO VIDEO CONVERTER 

7. MULTIFUNCTION DISPLAY SYMBOL GENERATOR 

8. CAUTION & WARNING 

9. COMPUTER & DATA ACQUISITION C&D 

10. ELECTRICAL POWER SUBSYSTEM DEDICATED C&D 


11. ALPHANUMERIC KEYBOARD 

12. HAND CONTROLLER (3 AXIS) 

13. TAPE RECORDER CONTROLS 

14. TBD 

16. CCTV CONTROLS 

16. TIME DISPLAY UNIT 

17. VIDEO SWITCHING 

18. HAND CONTROLLER MODE & ENABLE CONTROLS 
18. AUDIO UNIT 


Figure D-5. Pallet-Only C&D console. 


304 







DATA BUS 



CAUTION 

a 

• WARNING 


HARDWIRE 
TO SENSORS & 
OR BITER caW 


HARDWIRE 
TO CCTV & 
EXPERIMENTS 


POWER 

CONDITIONING 


HARDWIRE 
TO OTHER 
STATIONS 


AUOIO 

CENTER 


J 


Figure D-6. Pallet-Only C&D console block diagram 












D2. 3. 6 Weight, Power, and Volume Assessment 

Table D-3 presents the mass, power, and volume assessment for the 
Pallet-Only C&D console. 
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TABLE D-3. REFERENCE MODEL PALLET-ONLY C&D CONSOLE 
WEIGHT, VOLUME, AND POWER ASSESSMENT 


Unit 

Power 

(w) 

Width x Height x Length 
[m (in.)l 

V olume 
[m 3 ( in. 3 ) 1 

Weight 
[kg (lb) 1 

Advisory Panel 

40 

0.43 x o. 19 x o. 20 
(17 x 7. 5 x 8) 

0. 017 
(1020) 

4.54 

(10) 

Thermal Control Subsystem 
Dedicated C&D 

2 

0. 15 x 0. 18 x 0. 09 
(6 x 7 x :i) 

2.06 x 10" 3 
(126) 

2. 27 
(6) 

PACS Dedicated C&D 

2 

0. 28 x 0. 18x 0. 10 
(11 x 7 x 4) 

5. 05 x 10“ 3 
(308) 

4.54 

(10) 

Computer and Data Acquisition 
Dedicated C&D 

5 

0.43 x 0.09 x 0. 10 
(17 x 3. 5 x 4) 

3.9 x 10~ 3 
(238) 

4. 54 
(10) 

Electrical Power Subsystem 
Dedicated C&D 

4 

0.43 x 0. 18x 0. 10 
(17 x 7 x 4) 

7. 8 x 10 -3 
(476) 

6. 80 
(15) 

Tape Recorder Controls 

1 

0, 23 x 0. 15 X 0. 08 
( 9 x 6 x 3) 

2.65 X 10“ 3 
(162) 

2.27 

(5) 

CCTV 

1 

0. 13 x 0. 15 x 0. 08 
(5X6X3) 

1.47 x 10“ 3 
(90) 

1.81 

(4) 

Multifunction CRT Indicator 
Unit (2) 

200 

0.43 X 0. 37 X 0.43 
(17 x 14.5 x 17) 

0. 14 
(8380) 

27. 22 
(60) 

Microfilm-to-Video Converter 

40 

0.43X 0. 18 x 0. 34 
(17 x 7 x 12) 

0. 023 
(1430) 

9.07 

(20) 

Multifunction Display Symbol 
Generator 

75 

0.43 x 0.20 x 0.41 
(17 x 8 x 1G) 

0. 036 
(2180) 

13. 61 
(30) 

Caution and Warning 

5 

0. 43 x 0. 08 x 0. 20 
(17x3x8) 

6. 69 x 10“ 3 
(408) 

2. 27 
(5) 

Alphanumeric Keyboard 

2 

0. 43 X 0. 05 x 0. 14 
(17 X 2 x 5. 5) 

3. 06 x 10 -3 
(187) 

2.27 

(5) 

Hand Controller 

1 

0. 10 X 0. 20 X 0. 10 
(4 x 8 x 4 ) 

2. 09 X 10' 3 
(128) 

6. 80 
(15) 

Time Display Unit 

20 

0.43 X 0. 15 x 0. 08 
(17X6X3) 

5. 01 x 10~ 3 
(306) 

2.27 

(5) 

Video Switching Unit 

2 

0. 13 X 0. 15 X 0. 08 
(5X6X3) 

1.47 X 10 -3 
(90) 

1.81 

(4) 

Hand Controller Mode 
and Enable Controls 

- 

0. 13 X 0. 15 X 0.08 
(5X6X3) 

1.47 x 10 -3 
(90) 

0.91 

(2) 

Audio Unit 

40 

0. 18 x 0. 15 X 0. 08 
(7X6X3) 

2. 06 x 10“ 3 
(126) 

4.54 

(10) 

Console Wiring 

- 

- 

- 

13.61 

(30) 

Console Enclosure 

- 

- 

0. 909 
(55 500) 

79. 38 
(175) 

Total 

440 

1 


190. 51 
(420) 

Experiment Dedicated C& D 
(Chargeable to Experiments) 


0.48 X 0.91 x 0. 43 
(19 x 36 x 17) 
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APPENDIX E. ONBOARD CHECKOUT 


PRECEDING PASS BLANK MW: ' 



El. 0 ONBOARD VERSUS GROUND CHECKOUT TRADE STUDY 


El. 1 PURPOSE AND SCOPE 

The objective of having maximum onboard autonomy is assessed in this 
section. Program costs of onboard checkout as opposed to ground supported 
checkout are presented parametrically. Secondary considerations were the 
identification of checkout functions which may be done on the ground or onboard, 
performance of a functional allocation, and assessment of criteria which have 
an impact on the onboard versus ground checkout issue. 

This study is in compliance with Sections 4.8.15 and 5.6.3 of the Sortie 
Lab Phase B Study, System Requirements (Task 4. 1. 1) which states: 

• "Checkout equipment will be provided on board to accommodate 
ground checkout except where analysis clearly dictates the 
physical or cost advantage of providing specific functions in 
ground support equipment." 

• "Onboard checkout shall be utilized to perform malfunction 
detection and conduct subsystem and payload equipment 
checkout, monitoring, and fault isolation to a level optimized 
for cost, safety, maintenance, and repair requirements." 


El. 2 COST ANALYSIS 

Two approaches are taken in this analysis: 

1. Comparison of Spacelab program implementation using existing 
NASA ground support facilities to support checkout versus an autonomous sys- 
tem. 15 Specific references, assumptions, and estimates are identified in the 
trade. 


2. Performance of a function allocation and comparison of CPU opera- 
tion rates and memory requirements for a fully autonomous implementation 
versus maximized ground support implementation. This approach identifies 
and analyzes checkout functions and allocates the functions to the Spacelab or 
ground system. 


15. Ground support costs are extracted from the hearings before the Sub- 
committee on Science and Astronautics, U.S. House of Representatives, 
HR 15086, February 1968. 


F&SC2DMG PAGE BLANK NOT ELMEB 
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Two checkout concepts are compared, fully autonomous checkout and 
maximized ground support to checkout. In the fully autonomous operation, all 
functions are performed onboard; this leads to recognition of a failure and 
identification of the necessary repair or other action. Failure of the checkout 
system to perform in certain critical instances could force the crew to retreat 
to the Shuttle Orbiter and abandon the Spacelab. In the ground supported imple- 
mentation, all functions which can be performed on the ground are allocated to 
the ground leaving only those functions which must be done onboard as a result 
of criticality or functional performance. In certain critical situations added 
systems support could result in quicker problem diagnosis and avoidance of 
contingency operation modes. 

Checkout ground support equipment (GSE) and the launch vehicle have 
no bearing on the onboard/ground checkout issue and are not considered. 


E 1 . 2 . 1 Ground Cost Summary 

The ground cost summary is given in Table E-l. The rationale used in 
this analysis is given below: 

1. Range support and operational center support costs are identified in 
HR 15086. KSC costs are reduced 40 percent to reflect deletion of Saturn IB. 

2. The cost of the communications satellite assumes one channel, 
three satellites, Intelsat IV at $2M per year, per channel, per satellite. 

3. The nonrecurring cost delta for upgrading the ground processing 
systems for support to the Spacelab checkout is taken as zero, assuming that 
future equipment is rented and that this rental is covered by the recurring costs. 

To derive a checkout support cost, the yearly cost of $80. 5M must be modified 
by the considerations given in Table E-2. 

Tables E-3 and E-4 identify operational computer support at KSC and 
MSC and the application of these computers. It is estimated that 15 percent 
of this processing capability directly supports checkout, considering the 
normalized size of each processor and which processors support checkout of 
the Spacelab during prelaunch, launch, and the mission phase. 
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TABLE E-l. GROUND COST SUMMARY 


Item 

Cost 

(M&/yr) 

Source 

Remote Sites Including 
Ground Communications 

12.0 

Estimate 3 

Center Supports 

KSC 

MSC 

50.0 

12.5 

p. 315 HR 15086 

C ommunic ations 
Satellite 

6.0 

Intelsat IV Report 

Total 

80.5 


Nonrecurring Cost 

0 

Assumed to be included 
in above recurring cost 


a. Six remote sites are assumed. 


TABLE E-2. GROUND COST MODIFICATION 


Consideration 

Factor (%) 

Rationale 

Percent Devoted to 
Operations Versus 
Other Functions 

46 

47:41 ratio, i 

p. 316 HR 15086 

Percent Devoted to 
Spacelab Program 

30 

Spacelab shares cost 
with other programs 

Percent Devoted to 
Checkout 

... 

15 

Based on examination of 
data processing at KSC 
and MSC . See Tables 
E-3 and E-4, 

Total Recurring Cost 

For Checkout: $80. 5M (9.46) (0.3) (0.15) = $1,6M/Year 
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TABLE E-3. KSC COMPUTER SUPPORT 


Computer 

Application 

DEE -3 
(SDS910) 

Monitors propellant loading 

DEE -6 
(SDS930) 

DDAS events recording 

RCA 110A 
(2) 

KSC launch vehicle checkout; Redundant 
machines at LCC and mobile lander; 
Sequencing, monitoring, limit checking 

DDP224 

110A tie-in-D; Sanders display system; simplex 

GE635 

(2) 

Redundant machines at CIF ; Formatting and 
routing of spacecraft and vehicle; data to MSC 
and HOSC 

CDC 16 OG 
(2) 

Redundant machines at ACE facility; Spacecraft 
checkout 


TABLE E -4. MSC COMPUTER SUPPORT 


Computer 

Application 

IBM 360/75 

(5) 

Real-time mission control; redundant pairs; 
System dedicated to simulation and training 

Univac 494 

Communications preprocessors; Redundant 
(dynamic standby) ; Two missions and be 
handled by one system; Third system for 
nonmission activities; CCATS 

Univac 1218 
(2) 

Processes USB antenna position programmer 
data; interface to 642B machines 

Univac 494 

APCU; Simulate remote site functions 

Univac 418 

Logger for simulation system program testing 
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El. 2. 2 Onboard Cost Summary 


summarized below. 

0 
0 


The onboard cost is 
Hardware Development 
Software Development 
Hardware Cost/Recurring 
Software Cost/Recurring 
Astronaut Cost 

The rationale used for this analysis is 


$ 50K per module (l new module/year) 
0 
0 

as follows: 


1. A generalized processor meets onboard checkout needs without 
additional design and development costs. 

2. Software development and implementation costs to support a given 
function are equal for onboard or ground system implementation. 

3. Hardware cost is based on extrapolation of current prices for a 
small space-qualified processor. The delta for some additional memory and 
an I/O channel for the onboard computer would be equal or less. 

4. Recurring software costs are assumed to be identical whether 
committed to a space computer or ground computer. 

5. The costs of astronaut support are considered to be equal for auton- 
omous and ground supported implementation. When anomalies occur 

( infrequent) onboard, participation for fault isolation and repair is required 

in any case. 


El. 2. 3 Results 

Figure E-l compares the cumulative costs of an autonomous onboard 
checkout system to a ground supported checkout system. Two curves are 
shown for the cumulative cost for ground supported checkout. The first curve 
shows the Spacelab program carrying 50 percent of the ground systems cost 
and the second curve shows it carrying 30 percent of the ground systems cost. 
The cost advantage of onboard checkout is very obvious. 
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YEARS 


Figure E-l. Cumulative parametric cost analysis for onboard versus 

ground checkout. 


These results are expected and, in fact, would be still more dramatic 
if part of the costs of communications preprocessors and other processing- 
support were included in the ground supported checkout curve. 


El. 3 FUNCTIONAL ALLOCATION 

An overall functional allocation for checkout is derived in Tables E-5 
and E-6 by estimating the complexity of each function and estimating the por- 
tion that must remain onboard to support critical functions. In Table E-5, the 
left-hand column lists checkout functions; the second column is an estimate of 
the percentage of the total checkout job each function represents considering 
required processing, computation, memory, and frequency of occurrence; 
column three is an estimate of the percentage of each function which must 
remain onboard. The conclusion from these estimates is that approximately 
60 percent of the total checkout function could be allocated to the ground. Table 
E-6 lists the functions and the rationale for the functional allocation. 
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TABLE E-5. ALLOCATION OF FUNCTIONS 3 


Functions 

Percent of 
Checkout Job 

Percent Allocated 
to Spacelab 

Net Mandatory 
Allocation 
to Spacelab 

Limit and Status Checking 

40 

10 

4 

Procedural Check 

5 

10 

1 

Trend Analysis 

2 

0 

0 

Fault Isolation 

1 

0 

0 

Data Acquisition 

18 

100 

18 

Frequency Analysis 

1 

0 

0 

Curve Fitting 

1 

0 

0 

Monitoring 

9 

10 

1 

Man/Machine Interface 

20 

75 

15 

Report Generation 

3 

10 

1 

Total 

100 

N/A 

40 


a. Estimates from earlier programs and studies. 


The trade study assumes an integrated onboard checkout system which 
makes use of a data bus and the Spacelab procesor as shown in Figure E-2. 
System implementation is similar for onboard and ground checkout emphasis. 
The difference lies in which computer performs monitoring, fault isolation, 
and processing support to the checkout functions. The difference between the 
two checkout processing modes is characterized in Table E-7. Noting that for 
ground implementation, certain functions are added, the conclusion is that 
commitment of part of the checkout function to the ground not only results in 
the duplication of functions onboard and on the ground but results in added 
processing functions to support the interface between the onboard processor 
and the ground system processor. 
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TABLE E-6 . RATIONALE FOR ALLOCATIONS 


Function 

Rationale 

Limit and Status Checking 

• Represents a high loading factor due to periodic requirement and 
number of data points; 40 percent. 

• 10 percent to remain onboard to respond to semicritical needs. 

Procedural Checking 

• Can be complex, but performed infrequently; 5 percent. 

• 10 percent to remain onboard to provide procedural checks on 
response to semicritical situation. 

Trend Analysis 

• Relatively few functions are amenable to trend analysis so it would 
be performed relatively infrequently, 2 percent. 

• No trend analysis must be done onboard since neither quick 
response nor crew participation is needed. 

Fault Isolation 

• Fault isolation can vary from very simple recognition of failure 
discretes to complex analysis of multiple interrelated faults; 
occurrence is very infrequent; 1 percent. 

• All critical failures must be accommodated outside the domain of 
fault isolation and repair; fault isolation can be allocated to the 
ground. 

Data Acquisition 

• Acquisition of data for checkout represents a high loading factor 
due to periodicity and the large number of data points; 18 
percent. 

• All data acquisition must be accomplished onboard. 

Frequency Analysis 

• Few devices will be amenable to checkout and fault isolation by 
these techniques; 1 percent. 

• Analysis of this nature can be committed to the ground, since 
response critical anomalies will not be treated by frequency 
analysis or curve Fitting techniques. 

Monitoring 

• Monitoring by onboard processors or other devices must be done 
for all checkout parameters on a periodic basis; the operation 

is not complex; 9 percent. 

• Checkout parameters which are critical must be monitored 
onboard; estimated to be 10 percent. 

Man/Machine Interface 

• The man/machine interface is used infrequently but is quite 
complex since checkout software must produce easily understood 
results (high level language required); 20 percent. 

• Most checkout results are needed onboard to cover periods when 
RF coverage is unavailable, to allow astronaut participation, 

and to provide results in terms of repair or other action. 

Report Generation 

• Report generation consists of periodically organizing data which 
have already been obtained; 3 percent. 

• All report generation may be accomplished on the ground, but 
some feedback to the astronauts is needed; 10 percent estimated 
for support to synopsis type report. 
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Figure E-2. Integrated checkout concept. 


TABLE E-7. FUNCTIONAL COMPARISON OF AUTONOMOUS 
CHECKOUT TO GROUND SUPPORTED CHECKOUT 


Type of 
Checkout 

Function 

Onboard Computer 

Ground Computer 

Autonomous 

• Performs all acquisition, monitoring,, 
fault isolation, diagnostics, etc. 

• Compiles checkout summary report 

• Accepts checkout summary and status, 
prints, disseminates, provides for other 
mission support functions 

Ground Emphasis 

• Performs all acquisition 

• Performs minimal monitoring, fault 
isolation, diagnostics, etc, 

• Sends bulk of checkout data to ground 

• Accepts checkout data 

• Performs most monitoring, fault 
isolation, diagnostics, etc. 

• Compiles and disseminates checkout 
summary report 

• Returns checkout results to station 

• Supporls man/niaehine interface 
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El. 4 MODULARITY AND FLEXIBILITY 


If the Spacelab program were to experience a discontinuity such as the 
unavailability of planned payloads, the cumulative cost of onboard checkout 
would flatten, whereas ground supported checkout costs continue the upward 
trend. The key point is that program flexibility is achieved by modularity 
resulting in minimum costs in the event that various program anomalies occur. 
Modularity can be achieved by providing autonomous checkout in each experi- 
ment module. 

In addition, a modular approach to checkout will accommodate various 
test requirements during manufacturing, prelaunch, and launch phases for the 
module (experiment, power, etc.) and is compatible with an integrated check- 
out design approach where each payload and Spacelab system will have its 
modular software package. 


El. 5 THE REAL PROBLEM 

The parametric cost analysis has revealed a significant cost differential 
favoring onboard implementation. The results are entirely reasonable since 
the ground support implementation considers the massive support given to 
Apollo, whereas onboard implementation is bounded by the fact of being onboard. 
However, the functional allocation exercise narrows the problem to the cost of 
a ground checkout processor versus an onboard checkout processor. A large 
operational ground support element must be avoided if a low-cost program is 
to be achieved. 

The ground duplication of checkout functions for systems assurance, 
backup, etc. , are examined in Figure E-3. The key point depicted is that 
implementation of some fraction of the checkout function or a backup capability 
will result in a step function in cost. The reason is that any implementation 
on the ground will force real-time or near real-time accommodation of check- 
out problems, resulting in on-line software support, redundant CPUs and 
displays, increased emphasis on communications reliability and an additional 
on-going operations support element. The operations support element pre- 
dictably will grow. 
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INCREMENT REQUIRED FOR 
ANY GOOD CAPABILITY 


o 

100 

0 20 40 60 80 100 

ALLOCATION TO GROUND VERSUS COST, % 

Figure E-3. Cost versus ground allocation. 

El. 6 CONCLUSIONS 

Summarized below are the salient points and conclusions based on this 
analysis: 

1. The cost analysis overwhelmingly favors onboard implementation. 

2. Functional allocation determines that about 40 percent of the check- 
out job must remain onboard. 

3. Allocation of checkout functions to the ground causes a net increase 
in processing complexity as a result of functional duplication and to support 
the onboard/ground interface. 



321 


4. The key problem is minimization of the ground support element as 
opposed to onboard or ground allocation. 

5. Each experiment to be flown or integrated with the Space lab should 
contain its own software module to provide for program flexibility. 

6 . The additional systems assurance that can be provided by ground 
system backup will not justify its cost. 

7. Frequency of testing over a short time frame should not affect the 
results of this study. However, the longer duration missions favor the onboard 
implementation due to the large amount of ground equipment that must be main- 
tained in a ready or near-ready status. 


E2.0 ONBOARD CHECKOUT REFERENCE MODEL 
E2. 1 INTRODUCTION 

This section presents an onboard checkout subsystem design reference 
model that was developed to meet Spacelab requirements. The test concept 
reflects the requirements to provide an onboard checkout system that performs 
the required functions and is optimized for cost, safety, maintenance, and 
repair. When implemented it will minimize the requirements. Most of the 
hardware required to perform integration testing, fault isolation, and per- 
formance analyses will be an integral part of the Spacelab subsystem. The 
test approach is not new as the basic concepts were in the Apollo program. 

This model it to be evaluated by a trade study. Adjustments to the model will 
be made where cost effective. 

Figure E-4 illustrates the study flow used in developing this model. 

The use of trade studies to evaluate performance factors against cost is 
depicted. The results of the trade studies are used to modify the reference 
model in order to optimize the cost of meeting overall checkout requirements. 

Performance analyses and fault isolation are two primary functions of 
the OBC . A system which is instrumented to meet fault isolation and perform- 
ance analysis requirements will inherently possess the characteristics 
necessary for higher level testing. In past aerospace systems it has been 
erroneously concluded that total cost in terms of hardware, software, and labor 
is independent of the procedural approach. A proven procedural approach is 
available which will minimize all three factors. This approach is reflected in 
Section E2.4. The technology risk is minimized as this process has been 
proven through the Apollo program studies. 
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AVIONIC SYSTEM CONCEPTS 
TEST CONCEPTS 
FAULT ISOLATION CONCEPTS 
TREND ANALYSIS CONCEPTS 


• RELIABILITY 

• WEIGHT/SPACE 
COST VS * AVAILABILITY 

• SOFTWARE COMPLEXITY 

• COMMONALITY 


OTHER AVIONIC 
REQUIREMENTS 


OTHER SORTIE LAB 
REQUIREMENTS 


• PREVIOUS STUDIES 

• GOAL COMPUTER 
LANGUAGE 

• SELF-CONTAINED 
READINESS AND 
FAULT ISOLATION 
STUDY 

• AUTOMATED FAULT 
ISOLATION STUDIES 



HARDWARE BLOCK DIAGRAM 
INTERFACE DEFINITION 
SOFTWARE DEFINITION 
CEI SPECIFICATION 


OTHER GSE 


Figure E-4. 


System definition for onboard checkout. 














E2.2 IMPACT SUMMARY 


Basically, onboard checkout requirements will be embodied in the 
existing Spacelab hardware. The computer, data bus, control and display, and 
recorders provide the basic flight hardware required for onboard checkout. 
Appropriate command and measurement capabilities which are implemented 
throughout the various Spacelab subsystems are utilized to perform the onboard 
checkout functions. 

The impact on the Spacelab is as follows: 

1. Control and display capability is required in the Spacelab and 
Orbiter. 

2. Computer storage and time from the Spacelab computer is required. 
The amount of each is ( TBD) . 

3. The data bus will provide the communication capabilities required 
for onboard checkout. 

4. Onboard recording capabilities are required during operations, 

5. Each subsystem design must be compatible with onboard checkout 
requirements. 

6. Some special purpose onboard checkout equipment may be required. 
This would depend on subsystem design, costs, etc. 


E2.3 REQUIREMENTS 

The Spacelab operations top level functional flow (Fig. E-5) was 
established by the Spacelab design requirements document dated December 1, 
1972. The various repetitive operations through which the Spacelab is cycled 
are shown in blocks 6 through 13 of the figure. The onboard checkout require- 
ments for these operations are defined in this section. 

A tabulation of fault isolation and trend analysis requirements follows: 

1. Onboard checkout shall be utilized to perform malfunction detection 
and to conduct subsystem and payload equipment checkout, monitoring, and 
fault isolation to a level optimized for cost, safety, maintenance, and repair 
requirements. 
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Figure E-5. 


Top level Space lab functional flow. 







2. The OBC shall be implemented in a manner which makes maximum 
use of data management, control and display, and sensor hardware required 
for normal subsystems monitor and control functions. 

3. Maintenance and repair of the Space lab will be accomplished on the 
ground as a prime mode. 

4. Primary maintenance of the Spacelab will be accomplished on the 
ground while demated from the Shuttle Orbiter. Maintenance of system installed 
equipment shall normally be limited to "remove and replace." 

5. Inflight maintenance of the Spacelab will be limited to minor adjust- 
ments and replacement. 

6 . The Spacelab will have no scheduled inflight maintenance performed 
during the 7-day mission. 

7. Commonality within the Spacelab and between Spacelab and the 
Orbiter will be considered throughout the design with the goal of common sys- 
tems, subsystems, and assemblies to minimize ground support equipment, 
personnel training, and maintenance repair times. 

It is assumed that the Experiment Module and Pallet have been previously 
integrated and can be referred to simply as "experiments" for the ensuing 
discussion of repetitive operations. 


E2.3.1 Experiment Integration (Block 6) 


The experiments and the subsystems have been previously verified 
individually as "modules" with interface simulators. This operation consists 
of physical and electrical mating of the experiments into the Spacelab. Elec- 
trical interfaces will be verified for continuity, proper voltages and currents, 
etc. The OBC will be utilized to support these interface checks as required. 

It is assumed that experiment-peculiar onboard checkout hardware and software 
will be furnished by the experimenter. 
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E2.3.2 Postexperiment Integration Verification Tests (Block 7) 


These tests are acceptance-typ e tests and include: 

1. Physical, functional, and operational interface verification. 

2. Overall systems test of all systems in normal flight modes. 

3. Electromagnetic compatibility. 

4. Redundancy checks which do not disturb the flight configuration. 

The OBC will operate in the normal flight mode. The test conditions which 
dictate a deviation from the normal flight mode will be of Tf add on" types which 
do not alter the basic flight software and hardware. Therefore, a special 
purpose hardware and software can be deleted for flight. 


E2.3.3 Spacelab Payload Launch Site Checkout (Block 8) 


These tests are intended to verify that the Spacelab is ready for inte- 
gration into the Orbiter. The OBC requirements seem to be the same as for 
block 7. 


E2.3.4 Spacelab Payload/Orbiter Integration (Block 9) 

This operation consists of installing the Spacelab into the Orbiter and 
verifying the electrical and mechanical interfaces. The OCS will support these 
interface checks as required. It seems that there is no additional impact on 
the onboard checkout system for support of this operation; the "adds ons" 
defined for block 7 should suffice for this operation. 


E2.3.5 Launch Operations (Block 10) 


Prelaunch servicing, countdown, and launch activities are performed 
in this phase of operations. The OBC will be required to support these activ- 
ities but definition of its operations is ( TBD) . However, if the cryogenic 
loading and high pressure gas loading are considered hazardous activities, 
remote control will be required. 
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E2.3.6 Flight Operations (Block ll) 


The flight operations can be divided into the five general areas defined 

below: 


1* Lift-off to Orbit — Whether or not the Spacelab is powered during 
the lift-off to orbit phase is not defined. However, assuming it is powered, 
the following would define minimal conditions: 

a. Power System — The Spacelab will receive power from the 
Orbiter. The fuel cells will be turned on in orbit. 

b. If measurements and active control are required during this 
phase the computer/data bus will be on. 

c. Cooling will be required if thermal effects of equipment being 
"on” cause the equipment to get out of temperature limits. 

d. Controls and display panels are off. 

e. Experiment pointing system is off. 

The OCS may be functioning to support remote control and monitor from the 
Orbiter or ground. All equipment will be monitored to assume correct status 
and operation. 

2. Preentry Operations — Prior to entry into the Spacelab the data 
management, power, and ECLS systems will be turned on. These systems 
are required to maintain a shirtsleeve environment in the Spacelab. The 
OBC will be functioning to support control and monitor operations from the 
Orbiter. 


3. Experiment Support Operations — After entry into the Spacelab, 
the equipment which supports experiment operations will be utilized. This 
would include the experiment pointing system, experiment data recorders, etc. 
The OBC will be functioning to support control and monitor operations from the 
Spacelab C&D panels. 

4. Closeout Operations — The various systems will be powered down 
to the minimum flight mode, with control and monitor capability located in the 
Orbiter. This corresponds with the preentry initial conditions. OBC require- 
ments are similar to those for preentry operation except the various systems 
are being turned off. 

5. Orbit to Landing — The conditions are essentially the same as those 
in item 1. 
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E2.3.7 Postflight Operations (Block 12) 


The immediate postflight operations include safing, powering down, and 
removal of data. The onboard checkout system will be required to support the 
safing activities. Definition of these operations is incomplete. 


E2.3.8 Spacelab Refurbishment and Tests (Block 13) 


The experiments will be removed from the Spacelab and it will be 
refurbished based upon evaluation of flight data. Retest of replaced items will 
be conducted prior to experiment integration. The OBC will support retest 
activities as required. 


E2.4 FUNCTIONAL APPROACH 

The onboard checkout system will utilize the existing Avionics System 
(see Figure E-6) to implement the requirements previously defined. These 
requirements will be reflected throughout the Spacelab subsystems design in 
the form of (l) built-in, self -test features for the computers, C&D displays, 
and the DIUs (via the computer) ; (2) test, via the data bus, of the other sub- 
systems by appropriate command and monitor subsystem capabilities; and (3) 
built-in, self-test features which are an inherent part of certain end items. 

It is assumed that experiment-peculiar test capabilities will be provided by the 
experimenter. 

At the present time, no hardware peculiar to the OCS is being defined 
pending firm requirements and further definition of measurement/data bus 
capabilities, analog function generating capabilities, etc. (it is also noted 
that the data bus may need a GSE interface for hazardous servicing operations) . 

The software peculiar to the OBC can be implemented by using Ground 
Operations Aerospace Language (GOAL) which is being provided as a part of 
the computer software. 


E2.4.1 Onboard Checkout System Operation 


E2.4. 1. 1 Initial Startup 

The computers, data bus, and displays are required as minimum 
support of real time operations. These items, supplemented with a flight 
recorder, are used to control, monitor, and record the discretes and analogs 
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Figure E-6. Spacelab Avionic System Reference Model 
































associated with the startup, operation, and shutdown of each of the flight 
subsystems. 


E 2 . 4 . 1 . 2 Monitoring 

During normal steady state operation of the subsystems, the operational 
status of the subsystems will be monitored by selected key measurements. 
Normally, these measurements will be across the various groups of assemblies 
that comprise a subsystem. In certain cases, real-time trend analysis results 
may also be displayed, see Section E2.7. As a goal, this type of monitoring 
will provide the crew with sufficient information to adequately perform redun- 
dancy management and to utilize flight spares. Display descriptions will be 
used to extract fault data on systems requiring inflight redundancy management 
and corrective maintenance. Multifunction CRT display of the C&D system 
will be used to display data. On the Support Module C&D consoles (Fig. E-7) 
the displays (item 4) are assigned to onboard checkout. Monitoring of onboard 
processors or other devices must be done for all checkout parameters on a 
periodic basis; the operation is not complex. Much of this monitoring can be 
under operator control using simple software such as display descriptions and 
operations monitors, see Figures E-8 and E-9. The control and display sys- 
tem (Support Module C&D console) is compatible. Control is through the 
keyboard of this console. Remote monitor and control would use essentially 
the same system (possibly identical in some cases) for operation from the 
Orbiter or ground. 

E2.4. 1. 3 Startup and Shutdown 

Most equipment failures occur, or are detected, during these opera- 
tions. It is assumed that the startup and shutdown procedures will be auto- 
mated. The standard command-response features of GOAL can be utilized 
through display descriptions to gather the command-response data for on line 
evaluation of fault conditions. This will permit utilization of systems 
redundancy /spares to complete the particular operation. 


E2.4.1.4 Data Recording 

A flight recorder will be used to gather data for post operations evalua- 
tion. The data will be used primarily to determine which line replaceable 
units have failed and need to be replaced with new LRUs. The time resolution 
on selected discretes should be on the order of 2 to 3 msec. The analog data 
is (TBD). 
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EXAMPLE B 

DD 351 DISPLAY DESCRIPTION 

S-IC DDAS SYSTEM 




DD 352 


•DEE-3640 (ONI 


•ON 

MDO 

1385 

K11 

* 


MD 1-450 

ON 


LDI 

1762 



OFF 

J1 1-345 (3.0) 


3.250 

MDO 

1386 

K12 

* 


K471-345 

ON 


LDI 

1764 



OFF 

MDI 2089 (OFF) 


YES 

MDO 

1387 

K13 

# 


K5-321 

ON 


LDI 

1766 



““OFF 

LD 1-1950 

ON 


MDO 

1388 

K14 

* 


MDI-85 

ON 


LDI 

1768 



“OFF 

LDI1910 

ON 


MDO 

1389 

K50 

* 


MDI-78 

ON 


LDI 

1770 



OFF 

Ml 03-340 (241 

1.490 


MDO 

1390 

K51 

* 


M009-115 (24) 

1.493 


LDI 

1772 



OFF 

•DS-17 (ON) 


•ON 

MDO 

1422 


* 


K472-345 

ON 


LDI 

1837 

K59 


OFF 

J1-345 (4.0) 

4.450 


LDI 

1836 

K87 


OFF 

•DS-9 (ON) 

•ON 


MDO 

1423 

K158 

* 


•AC-PWR-LAMP (ON) 

*ON 


LDI 

1839 

K60 


OFF 
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Figure E-8. Example of display description. 
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Figure E-9. Example of operations monitor. 


E2.4.2 Offline Data Processing 

Offline data processing of the flight recorder tapes will be used for fault 
isolation to the LRU level, performance analysis, time and cycle critical item 
update reports, etc. 


E2.4. 2. 1 Fault Isolation 

Fault isolation to the LRU level will be accomplished using matrix 
evaluation techniques (MET) . MET was demonstrated during the Apollo pro- 
gram, see Figures E-10 and E-ll. It is estimated that MET can perform at 
least 80 percent of the required fault isolation cases; the exceptions will be 
handled individually. It simplifies fault isolation by reducing it from a sequen- 
tial test process to a two-step data collection and data evaluation process. It 


334 



335 


DEI 3640 
jll -345 

MDI-2089 |0FF'f 
LAMP DS-17_ 

ORG CHANNEL 
AO JOtjiFRAME 
M2-J22 
1*1-322 ' 

JO iOth>MME_ J 
MSB - 3 40 

RACS maim channel 


METER N0_4 

D94-H9 
0153-119 
JU54-120 
LAMP^DS 28 ~ 
MPI-2034 
K85 120 
LAMP DS-36 " 

MDI-001 7 

K 124-120 
LAMP 6$ 27 
MDI0396 
LAMP OS-35 
CLCSEDMOIQOH 
LAMP OS-42 
MDI-0326 
LAMP_DS_ 1 43 
MQI-0327 

(101| 1681 

LAMP OS 50 
MOi 0022 
LAMP DS 44 

MOI 0025 

LAMP DS -45 

MIDI 001 5 

LAMP OS 52 
_MOIOO!6____ 

METER NO I ' 
METER NO 3 


LOX PRESSURIZATION SYSTEM 


FAULT STATEMENTS 


OHnnBannnEgmin»HnraiTirny nini niniFT3rn E7iran3FTii^i^^Egff3|T||^[gE]3EI]EI]EI3E3l 


JUiUlM 

m 


I 1 ! 0 0 D 1 10 I’l'l'l 


iai 


L 0 l 1 1 . 1 1 l 1 | | | 1 | | 


1 0 0 0 0 0 0 0 0 0 


0 0 I 0 I 0 j 0 ( 1 10 0 0 p 


o a i o o I i ) a o o 1 o 


OOUDOnun 

1 1 ■ 

0 0 0 0 1 ill 

- - ! , ■ 1 . 

' 1 i 

11111 

DO 0 0 0 0 

0 0 U 0 0 



Figure E-10. Example of MET from Apollo program 
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Figure E-ll. Example of MET from Apollo program. 
























requires that data be collected rapidly (real time) at the time of failure. The 
simplification comes in the evaluation process which is accomplished by 
comparing the abnormal status data with analytically derived status patterns. 
When a system is operating normally its status is reflected by a combination of 
command status and monitor status (measurements of performance), called a 
status profile. The command status is composed of "on" "off ? status of all 
commands which can control the system. The monitor status is a combination 
of analog and discrete data depicting the reaction of the system to that group 
of commands. Fault isolation can be accomplished by (l) collecting abnormal 
status profiles and (2) comparing or matching with a matrix of all possible 
failures. 


E2.4.2.2 Trend Analysis 

Certain items of equipment are amenable to trend analysis. Offline 
data processing is necessary to detect impending failures because historical 
data used for this type of trend analysis would not normally be stored in the 
flight computer. This type of analysis is particularly applicable to those sys- 
tems which are difficult and costly to operate on the ground. An approach to 
trend analysis is discussed in Section E2.7. 


E2.4.2.3 Other Reports 

Time/cycle critical item updates will be performed with offline proc- 
essing. A discrete events record of the previous operation will also be an 
output of offline processing. Events printouts for each sybsystem may also be 
printed for subsystem engineering evaluation and record. 


E2.4.3 Other Considerations 


There is some concern that fault isolation to the LRU level may be 
required during flight operations. Certainly it is possible to move this offline 
function to the onboard system. However, for this program, periodic telem- 
etering of flight recorded data to the ground appears to be a preferable 
alternative. 

During ground test operations, many of the subsystem sensors do not 
operate in the same manner as they do in flight. These particular sensors 
need to be identified and special provisions will have to be made to stimulate 
or simulate these sensors, as required, to successfully complete the ground 
test operations. 
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E2.5 ONBOARD CHECKOUT REQUIREMENTS FOR SUBSYSTEMS 

The Spacelab program requirements concerning onboard checkout must 
be reflected in the design of the subsystems. These requirements are given 
below and are of a general nature because they are subject to modification 
pending further studies and analysis. 

1. The computer, data bus, DIUs, and C&D panels require built-in, 
self -test features, either individually or in combination with each other. 

2. The measurements provided by the Spacelab subsystems will be 
sufficient for in-flight redundancy management and will provide sufficieint 
information to use flight spares. Aside from the normal redundancy provided 
in basic subsystems design, this implies early identification of flight spares. 

3. The measurements provided by the Spacelab subsystems will provide 
sufficient information to permit fault isolation to the LRU level. This requires 
that the subsystems designers identify the LRU elements in their subsystems 
and the measurements for LRU fault isolation. 

4. The measurements provided by the Spacelab subsystems will provide 
sufficient information to permit a trend analysis of those LRU items/subsystems 
whose useful life can be predicted through postflight analysis. This requires 
that the subsystems designers identify the LRU items/subsystems which are 
amenable to trend analysis techniques, identify the appropriate measurements, 
and provide sufficient information regarding the trend analysis technique so the 
data can be used for that purpose. 

5. The data acquisition system capabilities must, of course, be 
sufficient to support redundancy management, fault isolation, performance and 
trend analyses. Although the detailed requirements cannot be firmly established 
at this time the following comments /guide lines are suggested for design 
purposes: 


a. Time resolution of selected discretes should be on the order of 
2 or 3 msec. 


b. All discretes should have signal conditioning in the DIUs that 
reject changes of less than 2 msec duration. 

c. The time resolution of analogs, in general, should be good enough 
to define the normal expected startups and shutdown curves expected for the 
particular measurements. This degree of time resolution is probably what will 
be required for most performance analyses. 
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d. It is suggested that the time resolution of all analogs be limited, 
at the highest sample rate, to 1 msec. Signal conditioning should reject higher 
frequencies. 


e. EMC verification measurements require time resolution in the 
microsecond time regime. As a baseline, it is suggested that EMl/EMC be 
through the use of special ESE. Appropriate test points are required in the 
Spacelab subsystems for this purpose. 

f. Vibration/acoustic measurements that must go through the data 
bus will probably need special converters to be compatible with the data bus 
and computer. 


g. The time resolution of current measurements should be on the 
order of 2 to 3 msec. This is necessary because short circuits can trip circuit 
breakers (depending on their characteristics) in approximately 10 msec. It 
would be desirable to have current accuracies compatible with measurement of 
the various individual loads. This may be necessary for some trend analyses. 

The data recorder should record all data to sufficient detail to support offline 
fault isolation and performance analysis. The following comments /guide lines 
are suggested for design purposes: 

a. To minimize tape requirements, "change only” information 
should be recorded. 

b. At the beginning of each tape a complete status table of all 
discretes and analogs should be recorded. It is also suggested that this status 
table be recorded periodically (perhaps once per hour) . 

c. In most cases, six to eight significant bits of analog data are 
sufficient. (This may affect the word length of the analog data that is built 
into the hardware, ) 

d. To minimize the number of tapes, it is desirable that the crew 
be provided with some "edit” capability. This could suppress or lower the 
sample rate of cycling discretes. They could lower the sample rate or reduce 
the number of significant bits of analog data. 

e. To minimize the total number of tapes, provisions for trans- 
mitting taped information to the ground could be provided. 


339 



E2.6 ALTERNATE APPROACHES 


E2.6. 1 Measurement Oriented Fault Isolation 


Fault isolation can be accomplished at the time of failure using the 
Support Module C&D computer interface to conduct an automated program. 

This program uses (’’Fault Logic”) as the basis for a computer program which 
would sequentially conduct a test and select subsequent tests on the basis of 
results until the failed assembly is identified. One ATOLL or GOAL type pro- 
gram would be required to automate the procedures for each status measure- 
ment. 


E2.6.2 System Fault Isolation Procedures 


Several measurement oriented procedures can be combined. Entrance 
must be provided through a matrix for each measurement. These procedures 
tend to be complex and software is expensive for some hardware systems. A 
procedure of this type covering a data management system (SI-C DDAS) 
required 700 entry points and isolated faults to one or two of 3000 components. 
It was automated using ATOLL and required a running time of 3 to 28 min. 
However, this is the standard approach now used for most applications. It is 
not recommended for complex systems . 


E2.7 APPROACH TO TREND ANALYSIS 

Trend analysis is the evaluation of time related data for the purpose of 
(l) predicting the end of useful life of subsystems or components, (2) predict- 
ing impending failure of subsystems or components, and (3) detecting degrada- 
tion in subsystems or components. 

For Spacelab, the time related data available for trend analysis would 
go back to factory checkout.' Since all of this information would not be available 
to the onboard computer for calculations, it is convenient to consider trend 
analysis on ’’short term” and "long term” bases. 

The short term data available to the onboard computer begins on the 
ground during countdown operations and terminates on the ground with post- 
flight operations. Real-time trend analysis should be directed only at those 
items which can adversely affect the mission. Offline trend analysis utilizing 
long term data would, of course, be directed toward preventive maintenance. 
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At this point it should be noted that trend analysis usage in the space 
program has been minimal. A large number of functions do not appear to be 
amenable to trend analysis; consequently, a judicious selection of functions is 
required to get useful results. It is also noted that trend analysis is routinely 
used in the manufacturing industries to maintain machinery. Statistical 
techniques are useful to determine that machines /processes are drifting out of 
tolerance. Spacelab can profitably use many of the trend analysis techniques 
which have been developed in various industries. 

The Spacelab functions which appear amenable and cost effective to real- 
time trend analysis are primarily consumables (level and usage rate) . It is 
possible that certain temperatures (fuel cell, TCS, cabin temperature) may 
also be useful. 

The offline trend analysis will probably make extensive use of data 
obtained during the startup and shutdown of various subsystems. These 
transient conditions can be compared with previously obtained baseline data 
and operations data. The results should provide information on the following 
end items: 


1. Motors — Degradation. 

2. Pumps — Degradation. 

3. Filters — Clogging. 

4. Orifices — Wear. 

5. Valves — Response Time. 

It appears that trend analysis techniques can be used for real-time and 
maintenance operations. However, the reliability of some trend analysis results 
which would be used for maintenance is questionable. An evaluation of routine 
industry trend analysis techniques may uncover standard practives that are 
applicable to the space program. 
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